Tracking issue: productionize the jmt crate

[erwanor]

The JMT is in a good place in terms of features and has been battle-tested by frequent usage from both penumbra labs testnets and active development by sovereign labs.

However, there are still a number of holdovers from its previous usage in the Diem codebase, incomplete documentation, and inconsistent internal nomenclature around proof usage and generation. This has led to a number of bugs: #96, and more recently #100, and brings in higher technical risk when implementing new features (like update proofs #97), and optimizations like the batching API that sovereign is working on.

• jmt: remove obsolete leaf migration api
• jmt: remove obsolete fuzzing feature
• jmt: remove obsolete access path
• jmt: document ics23 proof generation
• jmt: document how update proofs work
• jmt: document the basic mechanics of leaf insertion
• jmt: refactor the leaf creation api
• jmt: improve the leaf creation documentation
• jmt: add CHANGELOG.md
• jmt: fix expect statements
• jmt: use Result<Option> for internal and outside apis
• jmt: consider testing coverage tools

The refactor tasks should focus on normalizing the internal nomenclature and improve the usage of idiomatic rust within the codebase. For example, the recursive routines frequently alias method arguments with routine-specific values that are semantically different. This seem to be done correctly for the most part, but is hard to read for no reason.

[erwanor]

Another thing that would be useful for testing is to have a TransparentHasher that will let us control the nibble path of a key and test specific configurations. I think this should also allow to refine prop testing around specific scenarios.