Bugzilla

Currently, to register mach commands, we import all necessary `mach_commands.py` files, interpret them and their dependents, and run all `@CommandProvider` decorators.
This causes two downsides:
* It slows the running of `mach`, because all modules are loaded, even those for commands who are unused. On my machine, roughly half of the `mach` startup time (`~450ms`!) is spent interpreting all these unnecessary modules
* We attempt to import modules [before activating a command's virtualenv](https://bugzilla.mozilla.org/show_bug.cgi?id=985141).

Additionally, there's the general issue of mach commands being registered simply by having their file imported. There's some action-at-a-distance implicit work happening there which is tough to follow. By registering commands in a pythonic way, we improve tooling support and usability.

Currently, to register mach commands, we import all necessary `mach_commands.py` files, interpret them and their dependents, and run all `@CommandProvider` decorators.
This causes two downsides:
* It slows the running of `mach`, because all modules are loaded, even those for commands who are unused. On my machine, `mach` takes `420ms` to start up, and roughly half of that (`~225ms`!) is spent interpreting all these unnecessary modules
* We attempt to import modules [before activating a command's virtualenv](https://bugzilla.mozilla.org/show_bug.cgi?id=985141).

Additionally, there's the general issue of mach commands being registered simply by having their file imported. There's some action-at-a-distance implicit work happening there which is tough to follow. By registering commands in a pythonic way, we improve tooling support and usability.