Chaincode-to-Client error handling

Summary:

It is hard for client applications to distinguish between different classes of errors (communication, Fabric Peer/Orderer issues, Application Contract errors). String parsing is in part a solution today - this is not reliable enough. Similarly, it is not easy for contracts to issue application-level errors.

The problem is that error information beyond the string message doesn’t flow back properly. This is partly because nobody has ever decided on the right pattern to follow, partly because the different chaincode and client API language implementations tend to have subtle differences in behaviour, and partly because the Fabric internals inhibit the flow of good error information back to the client.

- [ ] Confirm what the flow back from the chaincode is to the peer.
- [ ] What is the route through the peer/orderer for this structure for both 'evaluate/submit' transactions
- [ ] How this application error is then surfaced back to client applications
- [ ] How is the application error 'injected' within the chaincode