fix no-colors for help/version

[Ptival]

Opening this as a draft pull request because the current design makes this very awkward.

Paging @robdockins and @kquick who might have ideas/concerns.

Problem: The --no-colors flag I added does not remove colors for --help and --version. This was known, it was just much harder to support it for those than the rest.

Reason: Those options are parsed "early", before Crux parses the rest of the options, to terminate the program early. As a result, they are executed before the --no-colors flag is even read.

Solution: One can make the --no-colors flag be parsed early, so that the help and version commands can use colors appropriately.

However, this creates a cascade of other annoyances. First, to pass the options to the logger, we need to either:

• have the logger take two separate arguments, the "color options" (known early), and maybe the "other options" (known late),
• or bundle these two together into a CruxOptions ColorOptions OtherOptions,
• or what I did here is to carve out from the CruxOptions all those options that are related to output (that have sensible default values), so that we can pass those OutputOptions to the logger.

Of course, any attempt to de-flatten the structure of CruxOptions makes it somewhat annoying to perform nested updates without lenses. I'm not sure what's everyone's feeling on the use of lenses, and the use of Template Haskell to generate them. In this draft, I'm using lenses, but rather than bringing TemplateHaskell, which can make things slower, I just hand-write one lens.

This brings up the question of whether we should lensify the whole thing.

Because I chose a structure:

data CruxOptions = CruxOptions {
  // bunch of non-output options
  outputOptions :: OutputOptions
}

data OutputOptions = OutputOptions {
  colorOptions :: ColorOptions
}

there is still a very awkward setting of defaultColorOptions in cruxOptions :: Config CruxOptions, because it has to return a CruxOptions but cannot know the color options.

If we were to go an alternative route of:

data CruxOptions = CruxOptions {
  earlyCruxOptions :: ColorOptions,
  lateCruxOptions :: CruxOptions
}

data LateCruxOptions = {
  // all of the current options
  outputOptions :: OutputOptions, // except without ColorOptions...
}

we would get rid of this awkwardness, but manipulating this without lenses would also be unpleasant.

---

TL;DR:

There are four set of options:

1. Current early options
2. Color options
3. Output options (other than the color ones)
4. Other options (current options, minus the ones that are accounted in 3.)

• In order to bail early for --help and --version while respecting --no-colors, we need to parse (1.) and (2.) early.
• The printer needs to receive (2.), and optionally (3.), since it can have sensible defaults for (3.). It needs both for real runs, but only the former for --help and --version runs.
• It would be very weird to leave (3.) and (4.) together and create a default value for the whole thing just to send to the printer.

[robdockins]

I'm OK generally with lenses when they make things more pleasant; we use them in quite a few places. I do tend to avoid TH unless it is a big win. I'll leave it up to your judgment whether this qualifies.

[Ptival]

I just pushed a commit trying to use generic-lens instead.

I like the approach a lot:

• consumers don't even need to use the lenses, they see the unaltered record accessors
• setters get all the lenses benefits
• no Template Haskell, just some DeriveGeneric

[robdockins]

This seems fine to me. I guess it's a little annoying that we can't twiddle color options via the configuration file (if I've understood right), but maybe that's not too bad.

[kquick]

This seems very reasonable overall.

As a note, to fix #887 I'll need to make some adjacent changes, so if you think you'll land this soonish I'd rather wait to avoid conflicts.

[Ptival]

I can try and put out the final touches on this one this afternoon!

[Ptival]

Fixed and rebased (if you had already looked at this, you can only check the last two commits).

[Ptival]

@kquick got the all green, and addressed your concern and Rob's one.

Should I merge to unlock your work on #887?