[WIP] block height per output maintained in pmmr

[antiochp]

Alternative approach to solving the "coinbase maturity needs to be fork aware" issue in #559.

#215 attempts to solve this by committing to lock_heights in outputs (and revealing lock_heights in inputs).
The problem with this is discussed in #215. tl;dr introduces something like "output malleability" where a commitment can refer to multiple different output versions (on different forks).

This PR attempts to solve the issue by taking a step back and maintaining block heights in one of the sumtree pmmrs, specifically the rproof_pmmr (referred to as "witness data" here).

The rangeproof pmmr (I'm calling this witness data here, but this may not be technically correct for height info) was originally storing NullSum sum values (we had no need to sum anything).
We can use the sums here to store block heights.
The block height for an individual output is the height of the block that produced the output.
A sum of block heights is a range, represented by [lower_height ... upper_height] so any non-leaf node in the pmmr maintains the range of block heights for all nodes below it.
It is not immediately clear to me that this is a useful sum value. We only really care about heights for leaf nodes (outputs). But knowing the range of block heights might be useful for something for subsets of the pmmr?

To find the height of the block producing an output for a given commitment we can simply look in the rproof_pmmr at the same pos and retrieve the sum.

This has the benefit of being fully compatible with multiple forks. Whenever we rewind a pmmr and reapply blocks we rebuild the rproof_pmmr and reconstruct the necessary block heights in memory in the sumtree extension mechanism.
The block heights for the current chain are persisted in the pmmr to disk.

Summary of changes -

• get rid of the "header by output" index entirely
• store block heights as sum values in the rproof_pmmr
• wrap rproof and block_height up in WitnessData in the pmmr
• for current chain look heights up via sumtree
• for applying new blocks use the pmmr via the sumtree extension (fork aware)
• moved coinbase maturity validation from pipeline to sumtree.apply_block
• fixup DummyChain to more closely resemble what we are doing with heights

TODO -

• lots of cleanup and renaming

This is exploratory - mainly to see if we could leverage the sumtree/pmmr to include useful information in the sum values.
I'm not taking a position on whether we should...

Thoughts? @ignopeverell @yeastplume

[antiochp]

Closing this - after (extended) discussion on gitter we are going with a hybrid approach based on #215.
But - we are adding switch commit hashes to the output_pmmr (taking inspiration from this investigation into putting heights in the rproof_pmmr.
Closing this PR but keeping the branch around for reference.