Expose and use a getCommandsForTab test helper to factorize out code where test manually instantiate the commands object from the descriptor front.

Then, we may use this helper more broadly in order to force fetching the top level target via the TargetCommand instead of via descriptorFront.getTarget

Based on priliminary feedback given offline on attachment 9209797 [details], I'm morphing this bug into exposing all or most commands via an helper module called "CommandsFactory".

This would be somewhat similar to TabDescriptorFactory and may ultimately replace it.

The key goals here are:

• to completely abstract away RDP. Hide that there is a client and any front. By default this helper will create a local client with a simple DevTools server and instantiate the right descriptor.
• hide any setup sequence the commands may need. There is still this call to targetCommand.startListening which we do here and there. It may be benefitial to do this from such helper.
• have a clearer session/client/commands lifecycle. You create a commands object, use it and then destroy it. It then does close the client, cleanup any RDP thing that has to be cleaned up. This is a bit similar to first point, we abstract away any possible RDP implementation detail regarding lifecycle.
• have a unique entry point. You create a commands for a given context (tab, parent process, addon, worker, ...) and no longer have to know, nor use a descriptor, nor a client.
• address ownership hierarchy. This is rather the commands that manages the descriptor and client. In today's code the commands are owned by the Descriptor, which isn't ideal.

In the upcoming patch, I'm refactoring all callsites of DescriptorMixin.getCommands(). All but toolbox one which would require some dedicated work in order to make the Toolbox receive a commands object instead of a descriptorFront.
But at least, all tests are being cleaned up and the vast majority of the codebase is unified.

https://hg.mozilla.org/mozilla-central/rev/49df28af43dc