Better error handling and recovery when using custom batch pin functionality

Part of [FIR-17](https://github.com/hyperledger/firefly-fir/pull/17)
Follow-on to #1213

One major issue with the functionality added in the PR above is that it's possible to get into a bad situation that prevents FireFly from dispatching new messages within particular constraints. Specifically, if these criteria are met:
* You submit an `/invoke` request which includes a `message`, per the new added functionality
* The invoke request fails in a non-recoverable way (such as when the parameters to the smart contract are malformed or unacceptable)

then the message batch will be built, sealed, and sent to the smart contract, but the blockchain transaction will fail. This will be retried forever, failing every time, and blocking the batch processor from processing more work (see below for details of the blockage).

---

FireFly creates "batch processors" to assemble and dispatch message batches. One is created for each unique combination of these dimensions:
* message type
* transaction type
* author DID
* blockchain signing key
* group hash (for private messages)

In the "blocked" scenario described, no more messages for the blocked processor will be processed. Since this is limited to the new transaction type `contract_invoke_pin`, effective blockage scopes might be:
* all `contract_invoke_pin` broadcasts from a particular identity
* all `contract_invoke_pin` private messages from a particular identity to a particular privacy group

This is a very large scope of blockage - notably it is well beyond the scope of a single topic or ordering context.

In addition, for private messages, each message will claim a nonce/pin for each of its contexts (where a context is a unique combination of a topic and a group hash). If such a pin is assigned but never successfully dispatched, this will effectively kill that topic, as pins need to be processed sequentially, and a gap of this kind means no further message from that author will be honored.

---

Before the next feature release, we need some investigation into how the scope of such a blockage can be limited, how a user can most effectively avoid getting into this situation, and how a user can recover if this does happen.