Create a "feathered" wrapper around `shardtree` to enable tracking witnesses for multiple candidate chains

[str4d]

As part of enabling wallets to track multiple candidate chain tips (instead of implementing rewind logic for reorgs), it is necessary to track multiple alternative evolutions of the commitment trees in order to enable building witnesses at any candidate chain tip.

Currently zcash_client_* use the shardtree crate to manage a single datastructure for tracking all information about a wallet's notes. It includes checkpoint infrastructure to enable rewinding state.

The proposal in this issue is to transition to using shardtree to represent the stable base of the tree (for which we, along with zebrad, assume there is a single canonical chain), and then as a layer on top of that we track the commitment data for the last 100 blocks for all candidate chains that are observed. This layer would combine that information with the shardtree data to enable a caller to obtain witnesses for tracked notes anywhere within any of the tracked candidate chains.

Unlike zebrad, the data in shardtree would not be immutable; due to its structure mutations would occur as a side-effect of non-linear scanning, and we also want the capability to import new viewing keys. But semantically it would only be responsible for tracking data obtained from a chain that itself is treated as immutable.

The shardtree checkpoint infrastructure would then be repurposed for enabling old anchors within the stable chain section to be used for witness generation (which can be useful when a wallet has been offline for a long time, or when doing a rescan to import a new viewing key).