Add a 'Binary' builder

[jt-nti]

The current CCaaS builder is great for chaincode development and debugging however it is not simple enough when trying out Fabric for the first time. The old built in docker-in-docker chaincode support is superficially simpler but often causes problems when the chaincode fails to build, which can be hard to debug.

While a simple binary builder is unlikely to be suitable in a production environment, it would provide a more robust mechanism to deploy chaincode out of the box and give a better first impression. It may also make it possible to deprecate the old docker-in-docker approach in v2.5 and remove that mechanism completely in v3, although that would also depend on the ability to package Binary (and CCaaS) chaincode.

cc @denyeart @mbwhite

[jt-nti]

It might be nice to follow a similar pattern to the k8s builder and include details of the chaincode binary in a binary.json file (or a better name?!) rather than the actual binary. For example,

{
  "chaincode": "file:///path/to/binary",
  "checksum": "27871baa490f3401414ad793fba49086f6c855b1c584385ed7771e1204c7e179"
}

That would potentially allow chaincode to be downloaded by the builder using https://, either with an initial implementation or as a future enhancement.

[jt-nti]

Worth mentioning that all the peers in the same organisation would need to be on the same architecture to install the chaincode, and they would not be able to move to a new architecture. The intention for this builder is to improve the first use of Fabric, rather than for production networks, so that should be ok.

[mbwhite]

Possibility to go even further and add a signature verification of the binary maybe? But for development that might well be excessive - a checksum at minimum though.

So this would be a single checksum per organization...

[jt-nti]

Signature verification would be nice to have in a production environment but it's possibly excessive for this use case. That could certainly be included if the demand was there though.

There could potentially be a single checksum for all organisations if they share the chaincode implementation, but certainly no more than one checksum per organisation.

[denyeart]

This sounds reasonable to me, as a way to make building and deploying chaincode simpler for people trying out Fabric, while removing the docker-in-docker dependence.