Why not just flutter pub ... ?

Fixes #9799

flutter pub pub ... will work (pub is an alias to packages). flutter pub on its own would be tricky because we'd be mixing two namespaces, e.g. flutter pub get (which is managed by flutter) and flutter pub foo (which is managed by pub). Consider for example what you should output for flutter pub --help.

Fixes #9301

So you would do commands such as flutter packages pub publish? That seems inconsistent with flutter packages get. I'd prefer something like #9799

@mit-mit I think it'd be fine to also expose explicit commands (the way e.g. I added test or the way we do get), but given the limitations of ArgParser I don't see how to do arbitrary passthrough on commands in that way while still having some curated commands.

I'm also rather dubious of taking on the maintenance burden of having to track pub's command set (which we would have to do if we exposed everything as an explicit command instead of just pass-through).

I don't think we have added any new commands in for quite a while (maybe several years), so not sure I'm too worried about that.

pub is an alias to packages

Why not make a dedicated PubCommand that does exactly what your PassthroughCommand does?

Changing the behaviour of flutter pub would be a breaking change; the pub=packages alias predates this PR.

If we want to change this to flutter pub ... then I think it's important that we first fix dart-lang/core#25 so that this isn't exposed to people right away in the top-level --help. Aside from the output already being really long (e.g. it lists flutter precache and flutter fuchsia_reload which are really esoteric options today), and making it even longer seeming like a bad idea (it's already about 50 lines long), I'm concerned that people will go down into the weeds trying to troubleshoot problems by directly manipulating pub.

Discussing with @Hixie, we'll likely to need a dedicated flutter publish anyway to provide our own validation logic around publishing a Flutter plugin. flutter packages pub is intentionally buried so as to avoid giving the user the impression that we support the gamut of subcommands that are supported by pub.

LGTM