Add a command which will allow to analyse gas usage on the blockchain.
The command can be executed by running:
```bash
./neard database analyse-gas-usage
```
The command will look at gas used in all of the blocks,
shards and accounts, and print out an analysis report.

This commit just adds the command, the implementation will
be added in the following commits.

Add a flag that can be used to specify how many latest blocks
should be analysed using the analyse-gas-usage command.

Now running:
```bash
./neard database analyse-gas-usage --last-blocks 1000
```

Will go over the last 1000 blocks in the blockchain
and analyse them.

For each block we want to gather information about how much gas was
used in every shard and account.

Gas is used when transactions and receipts are executed, and every
such execution produces an ExecutionOutcome, which is saved in the
database.
We can read all ExecutionOutcomes originating from a given shard
from the database, and get all of the needed information from there.
Every ExecutionOutcome contains the AccountId of the executor
and the amount of gas that was burned during the execution.
It's everything that is needed for analysing gas usage.

Usage from all blocks is merged into a single instace of GasUsageStats
and the interesting pieces of information are displayed for the user.

Add a flag that can be used to specify a range of blocks
to be analysed.

Now running:
```bash
./neard database analyse-gas-usage --from-block-height 120 --to-block-height 130
```

Will analyse 11 blocks with heights in range of [120, 130]

The logic of converting command line arguments to block iterators
has been extracted to the block_iterators module. In the future
it'll be possible to reuse it for another command that wants to
analyse some subset of blocks.

For each shard, calculate the optimal account that the shard could
be split at, so that gas usage on both sides of the split is similar.
An exact split isn't always possible, because it's possible for one account
to consume 40% of all gas, but the function tries its best to make it fair.

Information about optimal splits is displayed for the user.

Find the accounts that consume the most gas and display
them in the analysis. This information is interesting,
because it might turn out that one account consumes 50%
of all gas.

GasUsageInShard::merge() merges results from two instances of GasUsageInShard into one.
The merge is performed by adding information about each account from the other shard.
Then used_gas_total is updated as well. However this is the wrong thing to do.
Calling `add_used_gas` already increases `used_gas_total`, so doing it again
doubles the total gas, which is incorrect.

Fix the bug by removing the line that doubles the gas.

The field GasUsageInShard::used_gas_total keeps the total amount of
gas used in a shard. The problem is that keeping it in sync with the
rest of the struct requires special care and is prone to bugs.
A mistake in this logic has already caused one bug in calculating
shard splits. It's safer to get rid of the field and just calculate
the total amount of used gas when needed. It doesn't take that long
to calculate this value from scratch.

The previous implementation of calculate_split() worked okayish,
but it had some faults.

The first fault was that it split the shard into two halves where the left
one consistend of accounts smaller than the boundary account. This doesn't match
the logic that NEAR uses for boundary accounts. In NEAR the left half includes
the boundary account, i.e it's <= boundary_acc, not < boundary_acc.
The new function uses the same division as NEAR: (left <= split_account), (right > split_account).

The second fault was that the old function looked for a split where gas_left >= gas_right.
It isn't easy to prove that this is the optimal one - why is the left half supposed to be bigger?
Let's implement it in a way that is easier to understand. The new calculate_split()
looks for a split that minimizes the difference between the two halves. This makes sense,
we want the halves to be as similar as possible.

The commit also adds unit tests to make sure that calculate_split() works correctly.

When splitting a shard into two halves the shard is divided
into two on the split_account (boundary_account).
The split should look like this:
left < boundary_account
right >= boundary_account

Previously I misunderstood the semantics and implemented the split
as if it was left <= boundary and right > boundary. Fix it.

Previously gas usage of some accounts was displayed as percentage
of shard split half, but this was hard to reason about.
Let's change it to a percentage of total gas usage on a shard.

…ight%)

…ition of split

I guess VSCode froze and didn't run format on save :C