[LiveLogger] Tweak terminal UI to focus on in-progress work

[baronfel]

The current LiveLogger display can struggle with long lists of projects, pushing information about currently-building projects off of the screen. We should address this by collapsing information into three sections, focusing on in-flight projects.

The viewable area of the screen should contain three kinds of information:

• A collapsed line describing the number of projects completed during this build. This should be kept up to date as more projects are completed.
• Lines showing all in-progress builds that are currently blocked by other projects that are building. This is typically the result of some Target calling the MSBuild task on other project(s) - we should explicitly state this on these lines. The below is an example, but the core idea is to identify the dependent projects, and the specified target. There may be zero of these lines, depending on the point in time we're looking at.

./MyApp.csproj
- Waiting on `MyLib.csproj` to build the `compile` target

• Lines showing all projects that are actually being built at this time. This output should be what we're used to seeing in LiveLogger right now - warning/error output aggregated over the course of that built target.

[edvilme]

For point 1, does that mean also hiding warnings and high priority messages (including output) for finished projects?

[rainersigwald]

I don't think we know that for sure yet. I lean toward keeping them (if there's room after all the more-likely-to-be-relevant-now stuff).

[rainersigwald]

Lines showing all in-progress builds that are currently blocked by other projects that are building. This is typically the result of some Target calling the MSBuild task on other project(s) - we should explicitly state this on these lines. The below is an example, but the core idea is to identify the dependent projects, and the specified target. There may be zero of these lines, depending on the point in time we're looking at.

./MyApp.csproj
- Waiting on `MyLib.csproj` to build the `compile` target

I think there's a progression we can go through here. It'd be great to have that level of detail but it's not easily exposed in the logging we have today.

1. Trivial: special-case the MSBuild task to indicate to the project that called it that it's in a "waiting" state (with no further specific information).
2. Hopefully not too hard: scrape inputs to the MSBuild task to assemble a list of projects that are being waited on and display them
3. Advanced disambiguation: we may have to do some disambiguation here that isn't easy. To map to our understanding of a project, we'd need to apply the global property changes from item metadata on the Projects input + the current project's global properties.
4. Additional understanding of requested targets and/or linking to in-progress builds that are blocking this thing.