feat: let .corepack.env be a lock file

[aduh95]

With #642 and #643 landed, we can consider using .corepack.env as a lockfile. If the package.json defines a devEngines.packageManager, we can accept an env variable that defines the exact version Corepack should be using; if that version is put in a .corepack.env (Node.js 20+ users only), it's effectively a lockfile.

I'm not a fan of the env variable name chosen, happy to use a different one.

Fixes: #402
Fixes: #95

[styfle]

To be clear, this is only going to update .corepack.env if it already exists.

Its not going to create .corepack.env if it does not exist, right?

[aduh95]

To be clear, this is only going to update .corepack.env if it already exists.

Its not going to create .corepack.env if it does not exist, right?

Yes correct, if it exists and contains the env key – so it’s currently opt-in, I think we could discuss whether we want to flip that to opt-out once the parseEnv thing is no longer experimental.

[arcanis]

Why do we need that considering that packageManager can already be used as a lock for devEngines.packageManager?

[aduh95]

Why do we need that considering that packageManager can already be used as a lock for devEngines.packageManager?

So one can git ignore it I believe is the ask

[arcanis]

I'm not sure I follow the use case. Why would they use Corepack (or devEngine) if they don't want to lock the version in the project?