POC: push plugin enablement into plugin components

[michaelpj]

This implements a version of what I describe in [this comment] on the fourmolu plugin as a POC. The goal here is that:

• CPP moves to plugin components, rather than the integration point
• Plugin components always export a plugin descriptor, it just might provide nothing and say it is disabled
  • This can be helpful for our users, to tell them that things are disabled
• Plugin components always build, even if the flag is turned off
  • This is useful since cabal actually always tries to solve for all the buildable components, pulling in unwanted dependencies. This way that will happen, but it will be fine. (An alternative would be to just mark them as not buildable in this situation)
• Plugin tests are not buildable if the flag is off.
  • We could try and make them always buildable, and just have no tests, but that seems worse?

I haven't tried to make "being disabled" a first-class status or anything, a disabled plugin is just a plugin with no handlers and a description that calls that out. Maybe that's a mistake? I'm not sure.

[maralorn]

As a downstream consumer I like this a lot. It will make things easier for us.

In regard to the code I just wonder how good this scales. Does this mean that every file in every plugin contains a big CPP statement. I wonder if that is annoying to maintain?

[michaelpj]

I pushed an alternative version that instead has multiple different source directories.

[michaelpj]

WDYT @fendor ? It turns one module into four, which is not that nice...

[soulomoon]

An alternative would be to just mark them as not buildable in this situation

Will it improve the build time if most of the plugins are disabled.
It would be helpful to create the minimal HLS described in #2979 ?