No `Settings` in `DynFlags`

The two commits should describe themselves pretty well:

Break up Settings into smaller structs

As far as I can tell, the fields within Settings aren't intrinsically related. They just happen to be initialized the same way (in particular prior to the rest of DynFlags), and that is why they are grouped together.

Within Settings, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized.

In the spirit of GHC being a library, where the end consumer may choose to initialize this configuration in arbitrary ways, I made some new data types for those groups internal to Settings, and used them to define Settings instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.

and then

Inline Settings into DynFlags

After the previous commit, Settings is just a thin wrapper around other groups of settings. While Settings is used by GHC-the-executable to initalize DynFlags, in principle another consumer of GHC-the-library could initialize DynFlags a different way. It therefore doesn't make sense for DynFlags itself (library code) to separate the settings that typically come from Settings from the settings that typically don't.

There's also an immediate motivation in that speed up !959 (closed) I need to cache some former CAFs in DynFlags. The best way to do so would be make a PlatformWithCache containing the cache key (Platform) and cache values to make cache invalidation bugs less likely. (PlatformWithCache is essentially a view at a single argument into the memo table for a memoized function.) But Platform is in Settings, and PlatformWithCache has no place in Settings, only DynFlags.

The GHCi changes are somewhat more than the minimal because I don't find it very forward-looking to assuming the formerly-in-Settings options within DynFlags are static. Keeping track of the original DynFlags at the start of the GHCi session will surely produce an honest diff.

CC @bgamari

Please take a few moments to verify that your commits fulfill the following:

• are either individually buildable or squashed
• have commit messages which describe what they do (referring to Notes and tickets using #NNNN syntax when appropriate)
• have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places.
• add a testcase to the testsuite.
• replace this message with a description motivating your change

If you have any questions don't hesitate to open your merge request and inquire in a comment. If your patch isn't quite done yet please do add prefix your MR title with WIP:.