Multi-line status prompt ticker

[lihaoyi]

fixes #3546

This PR introduces a new MultilinePromptLogger that allows the status of multiple in-progress threads to be reported and viewed during a Mill evaluation:

Screen.Recording.2024-09-24.at.3.01.58.PM.mov

MultilinePromptLogger is basically a minimal translation of the current ticker API to work with a multi-line prompt. There's probably a lot of other interesting improvements we can make now that we are multi-line, but this is a decent start that lets people know what their parallel build is doing. The UI works correctly both during scrolling and not-scrolling, and uses the same minimal ANSI codes that the existing ticker uses, so hopefully we won't hit any more edge cases that we aren't already hitting today

From an implementation perspective, MultilinePromptLogger is mostly a drop in replacement for the old PrintLogger.

User-facing notes:

1. It prints multiple ticker lines at vertically at the bottom of the terminal, and has the logs printed above

2. It requires that you use .endTicker() after every .ticker("...") call, so we can know where we should clear the ticker status (previously they always just got overriden by the next .ticker call)

3. We need to introduce a withPaused{...} block so that when you're running REPLs and stuff the prompt is not shown

4. We only can support logs which end with newlines. This means things like interactive progress bars and other ANSI magic won't work in the scrollback. This is a limitation of the current implementation that is hard to fix without going for more advanced techniques, but should be enough for the vast majority of logs and is a similar limitation as a lot of other tools.

5. Console dimensions are propagated from the mill client to the mill server via a terminfo file specific to each server. This is used to size the prompt so it takes up the whole width and about 1/3 of the height. This happens every 100ms, so there may be some delay, but at least it means the prompt will right-size itself on next render. The regular cadence also means it shouldn't be a performance bottleneck

6. For non-interactive runs which lack a terminal, prompt WxH defaults to 120x50, and we tweak the rendering: we no longer render blank lines to preserve prompt height stability, we render less frequently and only if the statuses change, and we add a footer so the bottom of the prompt is clearly marked.

7. --ticker now defaults to true even for non-interactive runs, since the periodic display of prompt (I set to 60s intervals, if prompt changes) is useful e.g. for debugging stuck background jobs or CI runs.

Implementation Notes

1. The logger needs to extend AutoCloseable, since it uses a background thread to keep the prompt UI up to date. This renders every 100ms (arbitrary) to try and balance between prompt readability and latency. We have additional delays built in to hiding a status line and then finally removing it, to try and preserve the height so it doesn't bounce up and down too much as the set of running tasks changes

2. We re-use the ProxyStream classes to combine the stderr/stdout before re-splitting them. This allows us to perform some buffering, while simultaneously maintaining ordering of writes to each stream, while also allowing us to detect quiescence so we can only bother writing out a prompt when everything else is done and it won't get immediately over-written. ProxyStream.Pumper needed some tweaks to add hooks and remove client-specific assumptions

3. I experimented with having the ticker logic live in the Mill client rather than server, which would make more sense, but we need the server to have the ability to enable/disable the ticker logic to run console and similar interactive tasks, and so it has to live in the server

The old ticker remains available at --disable-prompt. Further improvements can come after 0.12.0.

[lihaoyi]

One remaining issue here is that ad-hoc usages of .ticker in build code now misbehaves, e.g. the coursier Downloading indicators below which do not disappear because they happen on separate threads (and are thus counted as distinct from the original task) and do not have a corresponding .endTicker call:

Probably need to tweak the API and semantics of .ticker a bit to make this work properly, will take a look tomorrow