View API cleanup

I'd like to share some doubts and results collected while working on the View addon.

The goal of this work is to clean the view API to ensure that the access to its functions and properties is completely modular -- AKA, the view should only be accessed via the commands exposed through the API.

Now, I found some frictions in the goal, stated as in below. I'll divide these frictions in two main areas:

• Commands not meant to be invoked on command line:
  Many commands are just thought to be called by other tools, in the code. Take all the commands that take or return flows e.g. @command.command(view.resolve). Registering these as commands expose them on command line, and this requires the command to:

1. Provide a way to send in args as str
2. Provide a way to print its output in DataViewer, still mantaining its type.

This can be solved by providing a 'front-end' for every type that is possibly returned from commands.

• Commands that return types not supported by Command Manager:
  Take this command (from my repo):
  def focus_flow(self) -> typing.Optional[mitmproxy.flow.Flow]:
  One of the most exploited 'view hacks' in the codebase is looking for currently focused flow.
  Those hacks expect the return type to be typing.Optional[mitmproxy.flow.Flow], and that makes sense, since when no flows are in the view, focus flow is None. Well, that return type is just unsupported by the Command Manager, so that command cannot be loaded.

Again, this can be solved by extending supported types, offering a good solution 'front-end' to represent Optional types (none message if type returned is None).

So, both of these issues can be solved, and this require an extension of the Command Manager. This seems to suggest a division between two classes of commands, user_commands and tool_commands. The latter would be masked from the console command line, since anyway, why the user is trying to "resolve" flows? That command is just intermediary, to resolve flows that have to be added, duplicated, removed, or filtered -- you continue.

But this extension is not to be made today, probably. I could try and look for some workarounds inside the view addon, to mantain the "You have what you need with commands" statement.

@mitmproxy/devs what are your thoughts on this?

Start by reading the View addon and Command Manager areas described in the issue, focusing on how view functions are exposed as commands and how return types are handled. The work would need a decided scope and design for separating user_commands from tool_commands and supporting flow and Optional return values; the issue does not name files or tests.