Conversion Tree Archiving

[murisi]

Assuming that in 10s a maximum of 200,000 conversion tree leaves can be updated, that epochs are a day long, and that there are 100 asset types; a conversion tree should would take 5 years of growth before it is untenable to update in 10s. Partly to mitigate this issue, conversion notes allow clients to refer to old archived conversion Merkle trees by specifying their anchors (much like spend descriptions allow a choice of an anchor from amongst a set).

In the ledger we should somehow add functionality to start building a new Merkle tree once the current one becomes saturated and add code to iterate these Merkle trees when querying for a conversion. (Old conversion trees not producing the latest asset types is not problematic because the client will do more conversions on the output until the asset type is the latest.) We should also figure out whether new trees should be padded in order to conceal which conversions clients are using.

[cwgoes]

@mariari in conjunction with the MASP work, we should at least make sure we have this noted (in the code)