feat: remove concurrent transactions and messages handling (#86)

<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
v                               ✰  Thanks for creating a PR! ✰    
v    Before smashing the submit button please review the checkboxes.
v If a checkbox is n/a - please still include it but + a little note why
☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->

## Description
This PR removes the concurrent handling of transactions and messages.
This is because it might cause some wrongful handling then a transaction
contains messages that perform opposite operations.

As an example, consider a transaction that contains, in the given order:

- one `MsgRevokeFeeAllowance` from Alice to Bob
- one `MsgGrantFeeAllowance` from Alice to Bob

If those messages are handled concurrently, since concurrency does not
guarantee the order of handling, the following cases are both likely to
happen:

1. the `MsgRevokeFeeAllowance` gets handled before
`MsgGrantFeeAllowance`
2. the `MsgGrantFeeAllowance` gets handled before
`MsgRevokeFeeAllowance`

If the parser is storing the existing fee allowances, then the following
results are equally likely to happen:

1. the database wil contain the proper fee allowance (if
`MsgRevokeFeeAllowance` gets handled before `MsgGrantFeeAllowance`), or
2. the database will not contain the fee allowance (if
`MsgGrantFeeAllowance` gets handled before `MsgRevokeFeeAllowance`)

Obviously, the second case is not the correct one and is only due to the
concurrent handling of messages.

The same might happen on a transaction level, with two transactions
containing similar messages.

To solve this, we need to remove the concurrent handling of transactions
and messages.

## Checklist
- [x] Targeted PR against correct branch.
- [ ] Linked to Github issue with discussion and accepted design OR link
to spec that describes this work.
- [ ] Wrote unit tests.  
- [ ] Re-reviewed `Files changed` in the Github PR explorer.