Move the pants-pyenv-install target to a sub-plugin

[thejcannon]

This was leftover from the prior PR, but split the magic into an opt-in plugin. I also added tests for it, yay.

Expected usage (which will be documented) is:
ENVVAR1=blah pants --concurrent --backend-packages=pants.backend.python.providers.experimental.pyenv.custom_install run :pants-pyenv-install -- 3.9

[stuhood]

Thanks for deferring this from #18352, as I continue to think this implementation is a bit contorted.

As mentioned in #18352 (comment), I think that providing a way to pass environment variables / flags to pyenv via options would:

1. allow for some common non-optimization use cases like declaring where openssl lives
2. allow for hermeticity of options, so that rather than relying on a user running commands in a particular order to mutate their cache, if they have an option set (perhaps via pantsrc) and a new python version comes in in pants.toml, their options are reapplied and the interpreter is rebuilt automatically
3. be less magical: setting an option leaves behind evidence that something is different in a user's environment. This current implementation requires a seperate plugin, and special documentation... whereas an option would be self explanatory.
4. be easier to implement:
   • hermeticity of options values would involve templating the options into the generated pyenv script so that its digest changed, and then nesting the named cache under the digest of the script (or under a direct hash of the options string, if you choose)

As mentioned elsewhere, I won't block though.

[thejcannon]

1. is definitely a use-case we should solve with options. 💯 on that one.
2. Is also one that's probably worth solving for, for simplicity sake.

4 I'm skeptical about. I'm very weary about unecessary re-installs (especially since this can't be cached), especially if a 30-minute install process is at stake.
Additionally, we haven't addressed the issue of "maybe a 30-minute install"-but-only-when-needed issue. That's about as bad UX as it gets 😂

I think in the end, I don't see a way around giving the user a level to pull on their own, when ready, to prime their cache in such a timesink way.

[stuhood]

Additionally, we haven't addressed the issue of "maybe a 30-minute install"-but-only-when-needed issue. That's about as bad UX as it gets 😂

I think in the end, I don't see a way around giving the user a level to pull on their own, when ready, to prime their cache in such a timesink way.

How would a user know that they need to re-run the magical step after a Pants version or Python version change had occurred? Their changes would just disappear.

[thejcannon]

Yeah OK the "I always want optimized Python" people aren't completely solved here. It's helpful to have this lever to pull, but it isn't obvious when it needs to be pulled.

My surface level thought here is maybe an extra option for "error and bail if you would install Python, I wanna do it myself". I'll think on it though.