Clarify `pex3 lock export` command.

Both #1404 and #1405 are difficult problems to solve in order to have a pex3 lock export command that works without caveats (i.e.: that exports a universal lock as a universal requirements.txt). The pex3 lock export command should be better documented and possibly modified to explicitly support only exporting to one (or maybe more) explicit local interpreters or foreign platforms.

[jsirois]

I’m going to modify the OP to narrow to dropping support for exporting universal locks as universal requirements.txt. Simply exporting for one (or possibly more) explicit interpreters regardless of the style the lock was originally created in - which is what is basically done now - makes sense.

[jsirois]

For the same reason that Poetry and pipenv have export commands: interop with the rest of Python ecosystem.

This is pretty vague. Fwict the lingua franca of interop is the venv and Pex already has tools to create those. It would be great to have a 1st party use case report of where a requirements.txt format file is what is needed and not a venv created from it. Maybe you have one of those use cases but I have none. Every tool I use understands venv no matter who creates it, Poetry, Pipenv or Pex. If there is actually a case where interop is furthered by a requirements.txt format file and not a venv created from it it would be good to know if that requirements.txt format file needed to be faithful to the lock; i.e.: for a universal lock a complicated “universal” requirements.txt acheived through environment markers and thus necessitating #1404 and #1405 or just a requirements.txt that worked for a specific local interpreter. That latter is tractable.