Cover the various cases and combinations around

• Using different "site packages sources" (VENV/SYSTEM/NONE)
• Using different command virtualenvs (build/common/doc)
• Imports in main processes versus imports in subprocesses

I'm going to test on top of bug 1761150, which simplifies system-sys-path management significantly

Verify that activating mach and command sites in various configurations
affects the sys.path accurately.
Also verify that the sys.path is correct between the "activated
process" and fresh processes spawned from created virtualenvs.

Finally, tweak existing path-management behaviour to be more consistent:

• Don't unnecessarily sort pths from requirement definitions - it's
  more consistent (and more dependable) to keep the provided order.
• Continue removing unwanted venv entries from the sys.path, but
  don't add them back (such as the $prefix entry)
• Always remove venv entries from the sys.path when the venv isn't
  being populated. Though this doesn't affect behaviour, it makes
  assertions easier and simplifies the runtime state a bit.

Depends on D143200

Verify that activating mach and command sites in various configurations
affects the sys.path accurately.
Also verify that the sys.path is correct between the "activated
process" and fresh processes spawned from created virtualenvs.

Finally, tweak existing path-management behaviour to be more consistent:

• Don't unnecessarily sort pths from requirement definitions - it's
  more consistent (and more dependable) to keep the provided order.
• Continue removing unwanted venv entries from the sys.path, but
  don't add them back (such as the $prefix entry)
• Always remove venv entries from the sys.path when the venv isn't
  being populated. Though this doesn't affect behaviour, it makes
  assertions easier and simplifies the runtime state a bit.

https://hg.mozilla.org/mozilla-central/rev/e2ef055ccbc2