Case split plugin

[Aster89]

This PR is for introducing the so called case-split plugin, as requested in #5013.

(In the following, me is myself and we is myself, @fendor, @MangoIV, and @AndreasPK.)

The change as of now needs lots of refinements (obviously beside getting rid of all the trace* calls I've peppered the code with, and beside squashing all commits together), especially these:

• currently, it's not clear to me how to affect the maximum number of patterns that are inserted by the plugin without also affecting the maximum number of uncovered patterns in the diagnostic error message;
  • ideally the two numbers should be independent, i.e., the diagnostic error message would still show maxUncoveredPatterns uncovered patterns, but the plugin would nonetheless insert _all_¹ uncovered patterns;
  • we agreed a good first strategy is to have the plugin honor maxUncoveredPatterns, because it's the least invasive approach, it doesn't require any additional code, one can only improve from there, and nothing prevents the user from triggering the plugin more than once to uncover more and more patterns (as noticed by Andreas, this could actually be the gist of some solution to the whole problem, i.e. trigger the plugin repeatedly until no uncovered pattern remains);
• as shown by several tests (e.g. T16.hs), the indentation of the patterns inserted by the plugins is sometimes too much, although correct,
  • and this is because I haven't fully grasped how deltaPos and related abstractions work; need to chat with @alanz about this;
• a few tests are not passing, testifying some decisions I haven't taken yet/use cases I haven't really a clear idea about:
  • I would assume the plugin should work for \case just as it does for case (see T12.hs), but maybe this is as much a generalization as having the plugin work with function definitions, so I guess we can drop this test, or maybe assume it as failing and link a new enhancement request to it?
  • The plugin works even if the expression being scrutinized is _, but the test doesn't pass (see T18.hs); I still don't know why;
  • how should the plugin behave when the type is not known, e.g. see T19.hs? I think it should just not offer any action.
  • when two case expressions, both incomplete, are nested (e.g. T14.hs), the plugin should offer an action for each incomplete case trigger for the innermost case expression which the cursor is on;
• the arrow should be -> or its unicode counterpart, honoring the -XUnicodeSyntax flag or previous patterns.

---

¹ Not really all, we don't want to split an all Ints, for instance, nor on an actual data with 100 ctors, presumably. Or do we?

[dschrempf]

Everybody is eagerly anticipating this change, thank you!

Given the many WIP commits, I just wanted to ask if you could sqaush or reword them. I guess you had this in mind anyways.

[Aster89]

Everybody is eagerly anticipating this change, thank you!

Glad to hear that!

Given the many WIP commits, I just wanted to ask if you could sqaush or reword them. I guess you had this in mind anyways.

Yep, see 3rd paragraph at the top :P

[dschrempf]

Ah, the second sub-clause :-P my attention had already shifted before that one, I apologize :-)! Thanks!

[MangoIV]

First pass. I think after you clean up the main logic a bit more and add some documentation there, I can take another look. :)

Very good work, looking forward to having this in HLS!

[MangoIV]

another small round :)

[MangoIV]

You can use for instance ExceptT for now. Is it clear why that's better?
And if you want to, you can try

newtype ExceptCT e m a 
  = MkExceptC {unExceptCT :: forall b. (e -> m b) -> (a -> m b) -> m b} 

and see if that's faster. But that doesn't have to be done now.