Add a hook for modifying the dynflags from a plugin

[isovector]

This PR changes the hls-plugin-api, adding a new pluginModifyDynflags hook to the PluginDescriptor. This field has type:

data DynFlagsModifications =
  DynFlagsModifications { dynFlagsModifyGlobal :: DynFlags -> DynFlags
                        , dynFlagsModifyParser :: DynFlags -> DynFlags
                        }

which are DynFlags endos for things you'd like to enable globally, and only for the parsing step. This PR uses the modifyGlobal field to pull some Wingman-specific functionality out of ghcide. The upcoming #1776 uses modifyParser to steal some Source Haskell syntax and allow inline tactic metaprogramming.

[wz1000]

I have to admit, I'm a bit concerned about how this interacts with recompilation checking.

[pepeiborra]

I have to admit, I'm a bit concerned about how this interacts with recompilation checking.

Why? As long as the choice of plugins doesn't change, I think that existing interface files should satisfy the recompilation checks.

[wz1000]

Why? As long as the choice of plugins doesn't change, I think that existing interface files should satisfy the recompilation checks.

The modsummary is changed using dynFlagsModifyParser before parsing, and this is the modsummary that is saved in the ParsedModule. This means it might diverge from the ModSummary returned by GetModSummary.

[pepeiborra]

Why? As long as the choice of plugins doesn't change, I think that existing interface files should satisfy the recompilation checks.

The modsummary is changed using dynFlagsModifyParser before parsing, and this is the modsummary that is saved in the ParsedModule. This means it might diverge from the ModSummary returned by GetModSummary.

Ok, so the risk is that the "parsed" DynFlags are used to produce the interface file, whereas the "modSummary" DynFlags are the ones used to check for recompilation, which could lead to false negative checks. Agreed, this would be nasty.

@isovector do we really need two modification functions?

[isovector]

@isovector do we really need two modification functions?

Well, that's up to yall! All I care about is getting a parse with -XQuasiQuotes enabled, but @wz1000 was concerned about that doing all sorts of horrendous things down the line. I'm happy to take directions here, but am far enough out of my expertise that I'm not sure how much I can contribute other than code.

[wz1000]

Perhaps you can restore the original ModSummary in the ParsedResult?

[isovector]

@wz1000 PTAL at d452740
@pepeiborra likewise, at 1170c2b