Consider packaging HLS as a single cabal package with multiple public libraries

[michaelpj]

Today, HLS consists of 37 packages. This is a huge pain to maintain and release, especially since we currently don't version them all identically. We almost always have issues with the Hackage release where some of the bounds aren't correct.

However, in reality they are all tested and built together by the HLS developers, and while in principle you can mix-and-match the versions of various plugins based on the bounds, it's not really something we need to support, or that brings value to users. Users mostly just want to get a HLS binary!

We do also have some users who build custom LSP systems using bits of HLS, notably SigmaIDE.

That suggests that we could just package HLS as one cabal package with multiple sub-libraries. They would need to be public sub-libraries in order to still enable the SigmaIDE use case.

That would simplify our lives a lot:

• Only one package
• Only one version
• Only one set of package metadata
• Common stanzas could be used project-wide

The reasons not to do this are:

• Stack doesn't support multiple public libraries (this doesn't seem like too big a deal, it only affects people who want to build stuff on top of HLS, which is a small set of users)
• Hackage apparently supports them, but it's perhaps not well-tested

The uncertainty is probably the best reason not to do this. It would be good to see some successful usage of multi-libs on Hackage before we jump in.

[michaelpj]

I think we could consider doing this. I think we should leave ghcide split out, but we could merge HLS and its plugins.

[michaelpj]

We did this!