A mechanical way to report build progress

[lukel97]

Whilst testing out show-build-info in the real world, it was changed so that it builds any dependencies that the targets might need. However this means it can take a while, and tools might want to relay the fact that cabal is busy building dependencies and setting up the environment.

I think it would be nice to have some sort of way to mechanically report what targets are currently built, and how many are left in a build plan.
I think this will have to be done within cabal-install somewhere in ProjectBuilding.hs. Currently show-build-info` has to set the verbosity to silent since Setup.hs outputs a lot of stuff to stdout.

And since stdout is already used to output the final resulting JSON from show-build-info, it would make sense to output the progress to stderr. Something along the lines of

{ "module": "Distribution.Simple.Setup", "component": "Cabal-3.2.0.0", "number": 12, "outOf": 120 }
{ "module": "Distribution.Simple.Blah", "component": "Cabal-3.2.0.0", "number": 13, "outOf": 120 }

Or equivalent, with each progress report being put per line.

[lukel97]

Perhaps a more important variation of this would be the ability to report various errors mechanically. For example if the solver fails to find an install plan, currently hie-bios or any other tool only has the human readable error coming from cabal, and a non-zero exit code, so the diagnostic displayed to the user in ghcide is usually something along the lines of "Couldn't parse result of calling cabal: ", which is usually displayed alongside the file that the user just happened to open.

If instead cabal show-build-info returned something like

{ "error": "Could not resolve dependencies:\n[__0] trying ....",
  "files": ["foo.cabal", "bar.cabal"]
}

ghcide could then show the human readable error message in a diagnostic for one of the relevant files, without hie-bios having to resort to munging or guessing where the cabal files are.
It's not much at the moment, but perhaps in the future if we are able to drill more information out of the solver, we could return hyper-detailed errors:

{ "error": "Could not resolve dependencies:...",
  "diagnostic": [{
    "file": "foo.cabal",
    "line": 23,
    "columnStart": 12
    "columnEnd": 24,
    "message": "Rejecting aeson-1.15.0.1 because bar => aeson < 1.15"
   }, {
    "file": "bar.cabal",
    "line": 23,
    "columnStart": 12
    "columnEnd": 24,
    "suggestion": "Loosen bounds on aeson to aeson < 1.16"
   }
}

This is only one such example where configuring/building may go wrong, and it seems like currently errors are usually just calls die or equivalent. So a mechanism will probably need to be introduced so that at least certain calls to die can provide the JSON output, if available and requested.