Cherry-Picked from OffchainLabs/nitro@flatmerkleapril16

It can be easy to look at small average step and hash times and miss
that the total time is what we're really trying to reduce.

I definitely had some incorrect assumptions about this data structure
which made it more difficult to learn. So, I'm documenting how it
works and adding some tests.

The simple_merkle test is currently failing because the `set` method
doesn't allow setting an index larger than the largest currently
set leaf's index.

There is some debate as to whether or not this is the correct
behavior. To run the test, use:

```
$> cargo test -- --include-ignored
```

At this point, the new root hash is eagerly calculated after each call to `extend`.

If this happened frequently, it should really improve the perfomance
of the machine.  However, it looks like it doesn't happen at all with
the benchmark inputs.

Previously, it could hit an index out of bounds if the new leafs
caused any parent layer to grow beyond its current size.

Hopefully, this will allow us to compare this branch's implementation
of a merkle tree to the one on merkle-perf-a.

The previous implementation was growing the same layers and
dirty_indices arrays because the clone isn't deep (I guess.)

There are a few different things going on in this commit.

1. I've added some counters for when methods get called on the Merkle
tree.

2. I've added integration with gperftools for profiling specific areas
of the code.

This allows me to profile CPU and Heap independently, and to enable
and disable the call counters independently.

This part of the code is obviously slow.
Let's see if we can improve it.

This is why there were all those unexpected "new_advanced" calls on
the memory merkle. The resizes were actually setting self.merkle
back to None.

There was a bug where expanding the lowest layer and calling set on
all of the new elements was not sufficient to grow the upper layers.

This commit also fixes a warning about the package-level profile
override being ineffective.

I don't think it's being used.

I have no idea why this is needed. But, it makes `make docker`
successful again.

The system tests are timing out because the implementation is still
too slow for large steps with lots of store and resize memory calls.