Feature: A programmatic interface for rustup (for IDEs and other complicated automation-around-rustup)

Rustup's stdout content is not an API : we change it regularly to communicate more clearly with users. However programs that consume the output of rustup have no means by which they can extract the semantic content - an API.

This is tied into various internal concerns such as the notification system, logging system, the async unpacking of content (and this will become deeper when when async spreads further inside rustup). See also https://github.com/rust-lang/rustup/issues/1875

Another possible interaction is an idea that is still in concept status / tribal knowledge, of having a (lifetime undefined) daemon, which might help with some of the file replacement concerns on Windows.

The high level sketch of an isolated form of this feature would be:

• some way to enable programmatic interface for install mode and rustup-mode (but not proxy-mode, at least not today).
• when in programmatic mode both input from stdin and output to stdout are structured semantic content using some reliable protocol.
• That is it detects errors including high-bit truncation, content truncation and insertion of unexpected content). Checksummed protobufs or similar might make a viable option.
• It needs to be something that is viable for IDE tooling (e.g. rust-analyser LSP, but possibly also the JS or Lua IDE glue-code that invokes the LSP); research is needed to understand constraints there.

Start by reviewing issue #1875 and the notification, logging, async unpacking, and IDE tooling concerns named here. Research protocol constraints for rust-analyzer and other integrations before proposing an approach. Done means there is an agreed design for programmatic install and rustup modes, including reliable structured input and output.