Refactor Idempotency logic to reduce boilerplate and increase code readability

See detailed discussion in https://github.com/hyperledger/firefly/pull/1406

### Suggested work
- [ ] Combine `txHelper` utility into `operations` manager
- Transactions are really grouping constructs of operations, and tracking the events for async completion
- There is weirdness that the `operations` helpers do not have direct access to the `idempotencyKey`
- There is a lot of boilerplate in other packages, joining together `txHandler` and `operations` functions
- [ ] Merge the `SubmitNewTransaction` and `ResubmitOperations` functions. Return options are:
- There is no idempotency key, here's a shiny new TX
- We've never stored a TX for this idempotency key, here's a shiny new TX
- TX already existed for idempotency key all done now - please return without error to the user
- TX was stored, but no operations were stored - here's the existing transaction ID
- All operations in the TX already reached `Pending` (or later), 409 to your user
- Something else went wrong
- [ ] (Separable) Update idempotency input handling to reject re-submit with different inputs
- Scenario:
1. Submit with `input1` and `idem1`, and get to a point of `Initialized` operations
2. Encounter failure that is not handled via internal retry and returns an error to you
3. Re-submit the API call, but this time with `input2` and `idem1`
4. Internally FF Core already stored the operations, so re-submits them with `input1` (not `input2`)
5. Transaction completes with `input1` - we ignored the `input2` you provided
- Improved behavior:
- Return an error stating that `input2` is not the same as `input1`
- Requires per-input handling to detect the operation inputs are the same or not