Still only implemented for (and used by) `LocalStore` atm

Copying a derivation output is equivalent to copy the output path,
except that it will also link the output to the path (with
`linkDeriverToPath` on the remote store)

Commands that accept store paths or installables as input can now take a
derivation path with outputs. Like when the input is a nix expr, the
derivation will be realised if needed.

Generalises `StorePathsCommand` to allow manipulating `Buildables`
rather than just store paths.

Not really useful atm as there's no way to retrieve this information,
but at least it's there

Build everything on the fly if `operateOn` is set to `Output`.
Also fix the computation of the closure in case `operateOn` is set to
`derivation`

Still needs a way to compute the closure of a derivation output

Rather than just storing the mapping `foo!out -> pathOf(foo!out)`,
we also record the dependencies of `foo!out`. This comes with a set of
needed changes

- New `drv-output-info` module declaring the types needed for describing
  these dependencies
- `linkDeriverToPath` is replaced by `registerDrvOutput` which has a
  slightly different signature
- new `queryDrvOutputInfo` to retrieve the informations for a
  derivations

This introcudes some redundancy on the remote-store side between
`wopQueryDerivationOutputMap` and `wopQueryDrvOutputInfo`.
However we might need to keep both (regardless of backwards compat)
because we sometimes need to get some infos for all the outputs of a
derivation (where `wopQueryDerivationOutputMap` is handy), but all the
stores can't implement it − because listing all the outputs of a
derivation isn't really possible for binary caches where the server
doesn't allow to list a directory.

Because it's legitimate to call it on an un-realised drv output, in
which case there's nothing to return

The previous version was assuming that only direct inputs of the drv
could be direct dependencies of drv outputs, which is generally false
(for example most c programs will depend on glibc while it won't be
provided as a direct dependency but as a transitive one through stdenv)

Otherwise the drvOutput->outputPath link can't be done on the remote cache
when using `nix copy` which breaks remote caching for CA derivations

…d path

Fix NixOS#4138 and allows copying drv outputs without having to copy the
whole drv closure

So that we can add another implementation for drv outputs