consider a `console-client` crate

[hawkw]

Currently, the tokio-console CLI has a bunch of code for connecting a gRPC client and streaming data, for converting the protobuf wire format into an internal data model, and for generating warnings and other analysis based on that data model. A lot of this isn't really specific to the terminal app at all, and is probably useful to other UIs, like a web app or native GUI as well. We could factor it out from the tokio-console crate into a separate library so that this code can be reused.

Some potential issues & design challenges

• Some parts of the internal data model use tui types like Span and Text rather than storing things as Strings etc. Obviously, the tui types don't make sense in the context of a web app...or even in a terminal application that doesn't use the tui crate. So, we shouldn't use those types in the console-client crate. However, in some cases, we store things using tui types rather than as Strings etc to avoid the overhead of converting between string representations and tui types, or to avoid re-evaluating formatting code repeatedly. It would be good to make sure we can make the data model generic without causing any significant performance problems for the terminal UI.
• This may have an impact on the velocity of console UI changes. Currently, all this code is just an implementation detail --- although it's pretty modular in nature, the cross-module boundaries aren't real APIs, and we can break them as much as we like in order to implement new UI features. If it becomes a crate of its own, though, this might no longer be the case. We should be careful about what parts of the data model and client code is factored out for this reason.

[hawkw]

cc @davidpdrsn and @sd2k, possibly relevant to your interests!