Bundle the new "k8s chaincode builder" with fabric-operator

[fabric-builder-k8s](https://github.com/hyperledgendary/fabric-builder-k8s) offers an exponential increase into the ease of use for consumers and operators working with Fabric Chaincode. With the k8s builder, the (person) operator simply installs a chaincode package with a declaration of a _specific and unique_ Docker image layer, referencing a container at a specific @ digest URL. The builder, in turn, leverages the "external chaincode" (a.k.a. Sykes lifecycle) events, managing the lifecycle of pods in Kubernetes as if they were a local process launched with fork/exec.

The builder, however, is not currently integrated well with the operator. To accept `type=k8s` chaincode packages, the chaincode builder binaries must be installed onto the file system of the peer pod, and a configuration stanza updated in core.yaml with the location of the binaries. In Phase I, we included the core.yaml configuration for the new builder, but did NOT install the binaries by default into the peer containers. To distribute the builder binaries, we created a custom peer docker image with the latest peer (2.4.4) code line, and overlayed the native Linux binaries onto the image.

Improve the "installation" of the k8s builder, such that "it just works" when creating Fabric networks with the `hyperledger/fabric-peer` docker image.

There are several techniques to get the k8s-builder binaries into the peer volume. Pick one and make it "right" :

- Update the k8s-builder project to generate a Docker image with ONLY the external builders.
- Launch the k8s-builder image as a sidecar to the peer, mounting binaries to the location specified in core.yaml
- Run the k8s-builder image as an init container, copying the binaries into a persistent volume share visible to the peer.
- Run a one-time "install" Job or script to copy binaries from a [release outputs](https://github.com/hyperledgendary/fabric-builder-k8s/releases/tag/v0.6.0) into a PV visible to the peer. (In general we should prefer distribution via Docker images, rather than manually copying pre-built binaries, if possible.)
- Something else?

This will likely collide or overlap with the existing IBP builder (sidecar) logic, which should not be modified by the introduction of the new builder. The new builder should _supplement_, not _replace_ the existing IBP builder.

This feature can reference the hyperledgendary prototype during development, but ideally will reference the builder once it has migrated to a [hyperledger lab](https://github.com/jt-nti/hyperledger-labs.github.io/blob/k8s-builder/labs/fabric-builder-k8s.md).

Start by reviewing the existing core.yaml builder configuration and IBP builder sidecar logic, then compare the listed installation approaches with the fabric-builder-k8s prototype and release outputs. Done means networks created with the standard hyperledger/fabric-peer image accept type=k8s packages while the existing IBP builder remains available.

Written by the indexing model from the issue text.