Issue title: Check types of missing definition quick suggestions
 Issue body: ### Current behavior:

Even though the type of `toLower` is known from the context (`Char -> Char`), "quick fix" purposes to import functions that, despite having the same name, are known not to be a correct type-wise (`Data.Text.Lazy (toLower)` for example).

![Screenshot 2020-07-07 at 13 41 51](https://user-images.githubusercontent.com/6209627/86769290-9dc76680-c057-11ea-8c64-bd8b6c6a7f69.png)
![Screenshot 2020-07-07 at 13 42 02](https://user-images.githubusercontent.com/6209627/86769306-a455de00-c057-11ea-95a8-20c7036fcb9a.png)

### Proposed behavior:

When the type of the undefined function is fully known, filter quick fixes by type.
 Comments: 
 Comment 0: This would be a really great improvement and i dare to say it should no be too difficult.
 Comment 1: There are two quick fixes involved here: suggest new import and suggest extend import. The code for these quick fixes is at:

https://github.com/haskell/haskell-language-server/blob/0b3bb10cd22cb265b7cbab84514178bcf4ae4f92/ghcide/src/Development/IDE/Plugin/CodeAction.hs#L796-L805

and at 

https://github.com/haskell/haskell-language-server/blob/0b3bb10cd22cb265b7cbab84514178bcf4ae4f92/ghcide/src/Development/IDE/Plugin/CodeAction.hs#L1241-L1250

In order to implement this, you will need to:
1. retrieve the type of the identifier I that is out of scope, 
2. the type of the import candidate C 
3. check if they are compatible 

I'm not really sure what's the best way to retrieve I, possibly parsing the error message?

Retrieving C should be easy - just look through the `tcg_type_env` in the `TcGblEnv`.

To check if they are compatible, I would do this with [`tcUnifyTy`](https://hackage.haskell.org/package/ghc-8.10.2/docs/Unify.html#v:tcUnifyTy). 
 Comment 2: The error message seems like a stable one to match against (data constructor has a slightly different message):
https://github.com/ghc/ghc/blob/4c87a3d1d14f9e28c8aa0f6062e9c4201f469ad7/compiler/GHC/Tc/Errors.hs#L1210-L1211
plus many GHC testsuite relies on this exact string.

I'll try with approach outlined in https://github.com/haskell/haskell-language-server/issues/754#issuecomment-864516151 and see how it goes.
 Comment 3: @pepeiborra Sorry to disturb you, I took a look at this and found the type of identifier can get from `TcGblEnv` by [`TcModuleResult`](https://github.com/haskell/haskell-language-server/blob/8d5e34706c6be18746297d8a7b47d5ab51915cbe/ghcide/src/Development/IDE/Core/RuleTypes.hs#L137), but candidates seem not. I have trouble connecting `ExportsMap` to `TcModuleResult`, do you have any suggestions?
 Comment 4: @July541 have you seen my recent comment in #2081 about this? It describes an easier approach, albeit too slow.  

To answer your question: To retrieve the type of the candidate you would need to use the GHC api, similar to what ghci `:info` does. I'm not on my PC but you can easily find the code for :info by grepping for infoCmd in the ghc repository. 
 Comment 5: I think we could try the direct ghc api approach until typed holes are usable, if using the API does not introduce too much complexity
 Comment 6: > To answer your question: To retrieve the type of the candidate you would need to use the GHC api, similar to what ghci `:info` does. I'm not on my PC but you can easily find the code for :info by grepping for infoCmd in the ghc repository.

Thank you, I'll try it.

 Comment 7: https://hackage.haskell.org/package/ghc-8.10.2/docs/GHC.html#v:lookupName might be helpful for getting the candidate types.
 Comment 8: Woohoo, thanks for your guide, it seems pretty nice!!!
 Comment 9: Do we have a function like `OccName -> ModuleName -> Unit -> Name`? I'm blocked by extracting type info from `HieDb`.

`HieDb` throws out a well-done type, restore the type seems not easy.

https://github.com/haskell/haskell-language-server/blob/dab8d009b25c07e84024ec4d339c6237a741b87b/ghcide/src/Development/IDE/Types/Exports.hs#L117-L132

https://github.com/wz1000/HieDb/blob/0e660aea0e2cf7a64c125b396b0229fcf679e6f7/src/HieDb/Types.hs#L221-L230
 Comment 10: This continue being unimplememted and it is as annoying that i am tempted to label it as a bug

![imagen](https://user-images.githubusercontent.com/54035/144575460-8ad0f13f-3dfc-42ad-bd6f-6b5d46263de6.png)

@July541 do you still planning continue working on that? do you have some work which could help other to continue this?
 Comment 11: If at least we would have #2436 it would make sense to propose definitions with other types, as you could apply `Change type signature` in a second step. But there are contexts where adding the proposed definition supposes code changes for sure.

but if we have several definitions with the same name and different types, they should be filtered unconditionally, imo
 Comment 12: As my latest comment mentioned, the difficult part is `retrieve the type of the identifier I that is out of scope`, as the identifier is from `HieDB`, restoring its type is not easy.

I'll have a look this weekend.
 Comment 13: Don't have a proper solution, feel free to pick this if anyone has ideas:(
{'source': 'GithubIssues', 'repo_name_with_owner': 'haskell/haskell-language-server', 'issue_id': 776399586, 'repo_stars': 1961.0}