Add sapling and orchard anchors to zebra-state

[yaahc]

Once we have implemented incremental merkle trees and can compute anchors we should:

• Update the state RFC for Orchard, based on the spec:
  • https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/rfcs/0005-state-updates.md
• Add sapling, and orchard anchors to QueuedBlock
• Add sapling, and orchard anchors to Chain
• Add sapling, and orchard anchors to FinalizedState

Unanswered questions about the finalized and non-finalized state:

What keys do we need to be able to look up quickly? For transaction validation? For treestate updates?

This changes how we index treestates in the state.

The state already has sprout and sapling anchors, and sprout, sapling, and orchard nullifiers.

Are there any rules about which treestates can be used for which transactions?

This might change how we maintain (Sprout?) treestates in the non-finalized state.

For example, can Sprout, Sapling, and Orchard transactions use the previous block's treestate?
(There are a lot of references to "finalized" treestates in the rest of the RFC, but I'm not sure if they are the same as the "finalized" state.)

The rest of the RFC mentions that Sprout transactions can use the treestate of any previous transaction in the block.

Yes Sprout is an annoying outlier in that transactions can point to a previous JoinSplit treestate within the same transaction as its treestate, so we need to compute more treestates/ trees (maybe just roots, not lots of copies of trees) in order to contextually verify Sprout tx's. Sprout can also use the final treestates of previous blocks.

But there is no need to track interstitial Sprout treestates for:

• JoinSplits in other transactions inside the same block, or
• JoinSplits or transactions in previous blocks.

Sapling and Orchard are easier in that you can only refer to the final treestate/root of a previous block.

Related issues:

#2425

[hdevalence]

Blocked on #1348 which introduces a PreparedBlock type to pass this data.