As we're going to have per-command virtualenvs, and we can't guarantee compatibility between commands, we're going to have to remove mach_context.commands.dispatch(...) support.

Hmm, there's a lot of cases where we're taking advantage of running subsequent commands in the same process by passing pre-parsed values directly into the called command with **kwargs.
There's cases like ./mach try that dynamically calls ./mach try again/fuzzy/auto/etc [*args], or ./mach hazards compile that ferries arguments to ./mach build.

We have couple options of solving this:

• Add infrastructure to pass along "pre-parsed" arguments to subprocesses (assuming that the parsed variants can all be serialized).
• Add infrastructure to convert parsed arguments back into --command --line --flags.
• Or, the easiest solution: continue to allow .dispatch() to exist, but validate that the virtualenv_name isn't changing between the calling and callee commands.

Even better, tweaked this a little further to a better abstraction level: forget dispatching, just guard against activating a command virtualenv from another command virtualenv.

Sphinx already runs within the ./mach doc command, which has the
docs virtualenv activated. Activating another virtualenv within a
Sphinx python file is redundant.

https://hg.mozilla.org/mozilla-central/rev/85c1380a7969

The Mach site is asserted to be compatible with all command sites, but
command sites are deliberately //not// asserted to be compatible with
each other - they're //supposed// to have the flexibility of being
able to be incompatible.

Accordingly, let's fail loudly if code tries to activate from one
command site to another.

This required updating the mozproxy tests, who would deliberately
activate the common site so they could call a mozproxy entry point
script. These tests were fixed by instead invoking mozproxy as a
module (-m) of the current python-test site.

https://hg.mozilla.org/mozilla-central/rev/349b88dc2b26