FFI supported types incomplete

### Target State:
Firefly utilizes a proprietary interface format (FFI) for exposing smart contracts through swagger web APIs. The FFI contains information to allow the API to self-document the parameters needed for contract calls and validate them before sending the contract.

### Current State:
The `buildFabconnectRequestBody` function in the core firefly repository serializes the request as JSON and provides the metadata from the FFI to fabconnect. The `processArgs` function utilizes the https://github.com/xeipuuv/gojsonschema library to perform validation of a go object against a schema (from FFI).

### Problem:
The current implementation only allows `string` or `object` types to be provided as top level properties. This requires treating all parameters as `string` or `object` types. This can be seen in the FFI provided for the PinBatch command which treats the `contexts` property which is actually a string array as just a string. This validation is successful, because the array is passed as stringified JSON.

Also consider that the Fabric Go SDK will automatically manage converting the stringified JSON into the correct parameters types for a function. This means that if the stringified JSON is valid, then there will be no issues and the contract will execute correctly. If the stringified JSON is invalid, the error will be thrown by the contract, and not by the API itself.

This results in a bad user experience because a user may expect more detailed information to be given by the API if input is malformed. The user needs to fetch the results of the transaction from firefly in order to see the error thrown by the contract, or even inspect the chaincode container logs to see the detailed error message - which may not be available to the user.

This also results in a performance hit with chaincode execution cycles being spent on transactions that could have been rejected at the API level instead of the chaincode level.

### Suggested Solution:
Fully utilize the JSON validation provided by the `gojsonschema` library to perform detailed validation of data being passed through the API.

### Justification for Solution:
This would provide a smoother user experience, and potentially improve network performance by prevent bad calls from getting into the pipeline at all.

Also, this would allow code generation tools to generate strongly typed FFI definitions from fabric contracts to avoid duplicated effort.

### Attempted Solution:
See Pull Request: https://github.com/hyperledger/firefly-fabconnect/pull/93