feat: check for renamed yarn.lock during install

[mdonnalley]

• Checks for oclif.lock to see if yarn should be rerun with the --prod flag
• Removes experimental feature introduced here: feat: use spawn instead of fork #638

@W-14010705@

[iowillhoit]

Should we check for yarn.lock first? Say npm@10 comes out and it allows you to package a yarn.lock. I could see a situation where someone has an old oclif.lock checked into their repo (even though we discourage that here) and the shipped yarn.lock would get overwritten with an old oclif.lock.

[iowillhoit]

QA NOTES

• Installed latest of sf
• cdd to the sf install directory
• yarn link @oclif/plugin-plugins
• Ran npm why @oclif/core

> npm why @oclif/core
@oclif/core@2.11.10
node_modules/@oclif/core
  @oclif/core@"2.11.10" from the root project

• Bumped oclif core in oclif-hello-world to @oclif/core@2.14.0

> yarn why @oclif/core
yarn why v1.22.19
[...]
=> Found "@oclif/core@2.14.0"

• Ran yarn oclif lock
• Published oclif-hello-world to verdaccio
• Installed with SF_NPM_REGISTRY=http://localhost:4873/ sf plugins install oclif-hello-world
• Inspect shows @oclif/core@2.14.0

> sf plugins inspect oclif-hello-world
└─ oclif-hello-world
   ├─ [...]
   └─ dependencies
      ├─ @oclif/core 2.14.0 => 2.14.0
      ├─ @oclif/plugin-help ^5 => 5.2.18
      └─ @oclif/plugin-plugins ^3.3.0 => 3.3.2

• Confirmed that there is a yarn.lock in ~/.local/share/sf
• yarn why in that dir

> yarn why @oclif/core
yarn why v1.22.19
[...]
=> Found "@oclif/core@2.14.0"

• npm why in sf install dir still shows 2.11.10

[iowillhoit]

Looks great!