v2 builder: accept backpack instantiations in the captured-unit set
The exe slice that consumes an indefinite backpack library ends up
materialising the instantiated form (a `+`-suffixed unit-id, e.g.
`bckpck-0.1.0.0-55b00c8f+Dwq5ijz...`) alongside the exe itself,
because the indefinite consumer's own slice produced no compiled
artifacts to compose in (cabal v2-build for an indefinite library
is "Up to date" and writes no `.conf`). v1 handles this with a
per-instantiation derivation (`lib/default.nix:369`'s
`components.library.override { inherit instantiations; }`); v2
doesn't yet have a slice-per-instantiation, so the instantiated
unit rides along inside the consuming slice's $out.
Three captured-unit changes:
* Read pkg-name from cabal's `dist-newstyle/cache/plan.json`
for bin-only units (no `.conf`). Falling back to uid parsing
misclassified OS-prefix-shortened names like `bckpck-...` as
a package called `bckpck` instead of `backpack`.
* Allow 0 target-package units (indefinite libraries register
nothing).
* Skip `+`-suffixed unit-ids when counting target-package units
— they're cabal-emitted instantiation byproducts, not the
slice's own target. The "no foreign package" invariant
(everything outside `expectedPackage` ∪ `allowedBuildToolPackages`
is rejected) still applies and is what catches an accidentally
rebuilt lib dep.
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4&s=80)
