Hotfix packages with unpinned var opts on load

[jrray]

Given a package with an embedded package that defines a var with a
default value, such as in:

install:
  embedded:
    - pkg: python/3.10.8
      build:
        options:
          - var: abi/3.10.8

Until the fix in #1302, these vars were not getting pinned
when the package is built and the stub created:

pkg: python/3.10.8/embedded[some-parent-pkg:run/3.10.8/P7SZECZD]
api: v0/package
build:
  options:
  - var: python.abi/cp310

This created a problem for solving correctly because
Satisfy<VarRequest> would incorrectly claim that this package is compatible
with any value for python.abi.

In order to fix solves for the existing embedded stubs, these missing
pinned values are pinned as the package specs are read from storage, so
they end up with the intended content:

pkg: python/3.10.8/embedded[some-parent-pkg:run/3.10.8/P7SZECZD]
api: v0/package
build:
  options:
  - var: python.abi/cp310
    static: cp310

Now Satisfy<VarRequest> will correctly reject this package as not
being compatible with, e.g., python.abi/cp311.

The best we can do is assume python.abi was not overridden to some
other value at the time the parent package was built and that the
default on the option is the appropriate value for the pin.

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/spk-storage/src/storage/spfs.rs	71.42%	6 Missing ⚠️

📢 Thoughts on this report? Let us know!

[jrray]

Some extra commentary... In the spirit of #1298 and friends, IMO it will help with bugs like this if/when an embedded package has a type that mandates that build options are pinned.

You could take things further since "build options" are arguably meaningless for something that can never be built: an embedded package.

You can also argue that a package, embedded or not, should not have a "build" section at all anymore, and anything from the "build" section of a recipe that is needed at runtime should be populated into the "install" section of the package at build time.

Similarly, an embedded package could arguably not have an "install" section and any of its runtime requirements should live in the runtime requirements of the component in the parent package that embeds this package.

Changes like these would go a long way towards simplifying how package dependencies are calculated and reduce the opportunity for bugs to sneak in.

For example, Package::runtime_requirements() returns a reference to the install.requirements field, The name might suggest that's all you need to figure out the runtime requirements of a package, however you still need to look at [some of] the build.options, components, embedded packages...

Handling components could be made easier if we baked out package specs for each component and treated them like separate packages. The InstallSpec of a built package would not have a components field anymore. It could also not have an embedded section anymore, just pkg requests for the stub package. The end goal being that install.requirements does become all you need to know the runtime requirements.

[jrray]

I can understand that this might be undesirable, but it is needed at least in the short term to fix bad solves. With the other fix in this PR in place, we can work on republishing packages to fix their stubs (or write some fixer script), and then I would be good with reverting this.