Add chaincode definition option to enforce execution on either LevelDB or CouchDB

Chaincode written to work against LevelDB will also work against CouchDB, as the CouchDB state database supports a superset of the chaincode APIs – everything LevelDB state database supports plus JSON query (GetQueryResult API).

There is one caveat - chaincode execution on CouchDB state database performs additional validation as required by CouchDB database itself:

1) Check for reserved fields in the top level of the JSON (FAB-8006): _id, _rev, _deleted, ~version.

2) Ensure keys are valid UTF8, and do not start with underscore, as required by CouchDB.

These restrictions are documented here:
https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html#state-database-options

One consequence is that chaincode executed and validated against LevelDB may not get validated on CouchDB peers. There may also be scenarios where range query results are sorted differently across LevelDB and CouchDB, causing differences in range query validation. For these reasons it is not advised to run a channel on a mix of LevelDB and CouchDB peers.

This work item would add an optional database specification on the chaincode definition, so that administrators could enforce the intended database target:

• chaincode intended for a key/value data store (such as LevelDB) that produces a writeset should only be endorsed if the transaction was simulated on a peer with key/value data store.
• chaincode intended for a JSON data store (such as CouchDB) that produces a writeset should only be endorsed if the transaction was simulated on a peer with JSON data store.