Old versions with incorrect bounds should all be deprecated

[georgefst]

An unfortunate consequence of belatedly adding version bounds (#533) is that Cabal will sometimes pick a very old library version. For example, currently, when trying to compile with GHC 9.14, Cabal sees that lsp-test-0.18.0.0 has dependencies which can't be solved with the latest base etc. and ends up trying to use lsp-test-0.14.1.0 instead. Which is from four years ago, and of course doesn't actually build (due to List re-export in this case).

Basically, there are versions of this library on Hackage whose dependency bounds are harmful lies. I think this is solved by marking them all as deprecated.

[georgefst]

It's possible that deprecating isn't actually enough to make the solver avoid the old versions, but base <0 should do it.

[fendor]

Deprecating sounds a bit heavy, is there anything fundamentally wrong with these versions? People could still use them, at least in theory.

Adding the correct upper bound on base could be the right thing to do, or telling cabal to use lsp-test ^>=0.18

[georgefst]

I suppose a less extreme alternative would be to do something like adding a base <= x to each version, where x is the version that introduced the List re-export. But that doesn't really solve the general problem. When, say, random-1.4 comes out, Cabal will start trying to use an ancient version of lsp that claims to work with every version of random.

telling cabal to use lsp-test ^>=0.18

That's what I'm now doing. But it doesn't help the next person who hits the same problem, and isn't familiar enough with Cabal's solver to realise what the problem is.

The ideal thing to do would be to work out all of the actual correct version bounds (or slightly-too-strict ones) for every past version of lsp. But I don't think we have any tooling that can prevent that from being tedious.