Make peer.sh more robust

[mbrandenburger]

PR #108 introduces a chaincode name prefix for private chaincodes. As this is a technical limitation and may disappear in the future we decided to hide this prefix from the end user.

PR #108 comes only with limited support for this name prefix and there is a lot room to improve this peer.sh and make it more robust against misuse and several situations. See the PR discussion for more details.

[mbrandenburger]

• Here a summary of suggestions:

The "DOCKER_IMAGE_NAME can only be used within instantiate" is not really true, what is true is "version is only provided by instantiate" as invoke and query use the version from latest instanstiated/upgraded. So wouldn't the really robust way be to do in invoke/query a ../../fabric/bin/peer.sh chaincode list -C ${CHAN_ID} --instantiated | | awk "/Name: ${FPC_NAME}/ "'{ print \$4 }' to get the version? (In fact, this could be right away the test, although doing a cross-check with DOCKER_IMAGE_NAME would make it even more robust) ...

Regarding upgrade changing FPC to non FPC-lang (or vice versa). I think this is simply something we cannot realistically support. Also not sure where it ever makes sense. I guess what could work eventually is upgrade from one FPC language to another one (e.g., if ever we would add go or wasm or alike ...)

Regarding chaincode list, override of course would solve it. I agree that we should be careful not to go overboard with peer.sh, though overriding chaincode list might just be a simple sed s/fpc// ? (this of course assumes no other code ever uses fpc as prefix but i guess that's a reasonably safe assumption we can do for now?)

• What about about double prefix situations?

[mbrandenburger]

We also need to prepare and check for multi-peer scenarios. See this #98

[g2flyer]

addressed in PR #113