Add support for `--no-pre-install-wheels` and `--max-install-jobs`.

[jsirois]

The --no-pre-install-wheels option causes built PEXes to use raw .whl files. For --layout zipapp this means a single .whl file is STORED per dep, and for --layout {packed,loose} this means the loose .deps/ dir contains raw .whl files. This speeds up all PEX builds by avoiding pre-installing wheel deps (~unzipping into the PEX_ROOT) and then, in the case of zipapp and packed layout, re-zipping. For large dependencies the time savings can be dramatic.

Not pre-installing wheels comes with a PEX boot cold-start performance tradeoff since installation now needs to be done at runtime. This is generally a penalty of O(100ms), but that penalty can be erased for some deployment scenarios with the new --max-install-jobs build option / PEX_MAX_INSTALL_JOBS runtime env var. By default, runtime installs are performed serially, but this new option can be set to use multiple parallel install processes, which can speed up cold boots for large dependencies.

Fixes #2292

[jsirois]

I'll attach some example perf numbers for the torch 2GB case here as soon as CI goes green. Suffice to say, this is both a build time win and run time win for that case.

[jsirois]

Reviewers: Thanks in advance - this is large. I did break it up into independent commits though, none of which is larger than 550 delta-lines, with most being ~100 delta lines. So instead of ~12 PRs you get 1 with 12 commits. I needed the 1 personally to work out all the titchy details comprehensively and ensure this all worked / vet it was complicated and actually required the 2 new knobs instead of just being the new default.

[jsirois]

Alright, #2292 now has perf analysis for the OP torch case. I'm still working on the 3 mac-specific IT failures, but this is ready for review.

[jsirois]

Alright - thanks @huonw and @kaos. I've added the perf analysis for small PEXes to the ticket which backs up what is expected: Builds of .whl file-based PEXes is always at least a little bit faster, Cold 1st runs is always a little bit slower and install parallelization is generally a loss. Although I'd love to not have knobs for these two new features, it seems necessary - there are unavoidable tradeoffs that are hard to justify removing from the user's purview.

[jsirois]

@kaos, I'm going to submit - I feel pretty confident I've covered the bases here - but I'll follow up with any feedback you have. There is refactoring and simplification to do as at least partly tracked by #2299 that further feedback will fall naturally into.