Implement account allow-listing for the partner mainnet

For the upcoming partner mainnet, we want to limit who can transact on the network based on their account IDs. To support this functionality, we need to implement a few things - mostly on the node, but some things will also need to be handled by the client/wallet.

### Keeping track of allowed accounts

The first thing we need is to track of is the set of allowed accounts. The number is likely to be relatively small - e.g., I'm not expecting more than 10K but we can even say 100K. These can be stored in a table or even in a flat file. My intuition is that putting it into a table may be easier - but it is not based on anything.

The next question is whether this is stored on the sequencer, full nodes, or validators. It seems like sequencer will be the simplest option because it would be a single place to update.

### Modifying the allowlist

We will also need to update this list periodically (e.g., adding accounts, and maybe sometimes removing some). I think the options here are:

- An admin-only gRPC endpoint which takes a list of accounts to add and to remove and updates the internal state. I would probably implement account addition first as it is critical functionality, and after that's working, implement account removal.
- A CLI command which does the same.

As a part of adding a new account to the list, we should also send a small amount (exact value TBD but probably around $0.01 USD) so that the account has enough funds to cover transaction fees for hundreds of transactions. This can be done by sending a `P2ID` note from the funding service account.

### Applying the account filter

Assuming that we store the account list on the sequencer, the check should be relatively simple:

As a transaction arrives and before it is accepted into a mempool, we check the account this transaction affects against the allowlist, and if the account is not there, return a specialized error to make it clear that the account is not permitted to transact.

If such a transaction is submitted as a part of a batch, we reject the whole batch.

### Making the list of accounts public

We will also need to expose the list of accounts via the gRPC interface. This is needed so that the client/wallet can preemptively check whether a given account can transact (and not try to execute transactions that fail). Given the number of accounts, the list will need to be paginated. I'm thinking we could track update time for each account and paginate based on that. This way, the client can download only w/e changed since the last time the client called this endpoint.

cc @igamigo and @WiktorStarczewski for this part.