Streamline code for getDocumentationTryGhc

[Anton-Latukha]

_{at least trying to}

Work towards #2348 & cleaning-up worked-with code on the go.

---

PR solves:

haskell-language-server/ghcide/src/Development/IDE/Spans/Documentation.hs

Lines 64 to 67 in bd0046b

	getDocumentationTryGhc :: HscEnv -> Module -> Name -> IO SpanDoc
	getDocumentationTryGhc env mod n = head <$> getDocumentationsTryGhc env mod [n]

As getDocumentationTryGhc is the main code that retrieves the docs from GHC - the PR provides the element retrieval code.

---

This PR is a stage toward provisioning the argument docs into the LSP interface. PR addressed some underlying code.

---

Initial master code conditions:

• getDocsBatch had a doc:
  

  haskell-language-server/ghcide/src/Development/IDE/Core/Compile.hs

  Lines 994 to 996 in 854d2c5

  	-- | Non-interactive, batch version of 'InteractiveEval.getDocs'.
  	-- The interactive paths create problems in ghc-lib builds
  	--- and leads to fun errors like "Cannot continue after interface file error".

• getDocsBatch not optimized for batch retrieval, it does 1 element retrieval for every element. (Locates & loads a module interface, retrieves 1 element, locates & loads another module interface, retrieves 1 element ...).

• getDocumentationsTryGhc (plural *s*) - in the project had only one use - in getDocumentationTryGhc (single) & so was its implementation.

• So, over the project only (single) (meaning getDocumentationTryGhc) was used - & all doc requests to GHC - were 1 element requests, which got wrapped into singleton & processed as a list & by list function down the codepath.

• So getDocsBatch both was externally invoked for 1 elem & internally was processing lists per 1 elem. Batch processing optimization is addressed in getDocsBatch for bulk processing #2371.

---

The results of the PR:

1. The non-interactive analog of GHCs getDocs - getDocsNonInteractive is created (for purposes mentioned in the initial doc above) it is designed for (all current requests) case of looking-up an entity.
2. Creation of getDocsNonInteractive allows to stop using getDocumentationsTryGhcs (plural) for getDocumentationTryGhc (single), which makes possible to remove unsafe head from the main code path.
3. Optimize the use case currently used everywhere.
4. Code shared between getDocsNonInteractive & getDocsBatch formed getDocsNonInteractive' & initTypecheckEnv which self-explained the code.

---

[Anton-Latukha]

https://github.com/Anton-Latukha/haskell-language-server/blob/19f65cb391e781ffba3dbecaedead01c3e967317/ghcide/src/Development/IDE/Spans/Documentation.hs#L71-L79

That IO gathering/handling seems strange to me, it catches IO exceptions from getDocsBatch.

While:
https://github.com/Anton-Latukha/haskell-language-server/blob/19f65cb391e781ffba3dbecaedead01c3e967317/ghcide/src/Development/IDE/Core/Compile.hs#L964-L982

There is a lot of Maybe & Either already around it & exceptions handling through IO on top of it. Code throws exception into IO just to catch it immediately. That means is somebody else uses getDocsBatch - afaiu would catch an exception.

[Anton-Latukha]

Separately have proper bulk-optimized retrieval: getDocumentationsTryGhc & its getDocsBatch, which goes into opened #2371 - with a bulking code.

I currently think singleton process should be kept, but element retrieval should be written as it is used - not for a list but for one element: getDocumentationTryGhc & its getDocsNonInteractive. - that is probably nice for hover-like docs retrieval (main agenda). From history of getDocsBatch & usage of it - getDocsNonInteractive should become a proper module-scoped function.

[Anton-Latukha]

Since HLS uses per-1-element retrieval from GHC:

The implementations for according mode are now provided.

And switched the code into it.

HLS now loads docs from module interfaces though proper mode implementation.