Add Regtest Support to the SDKs

[pacu]

Is your feature request related to a problem? Please describe.

Let's add regtest support to the SDKs, so that we can create more flexible scenarios on regtest and test them out with darksidewalletd.
I found that regtest is not stable and its time consuming to create long tests (more than 500 blocks), but its relatively simple to create a lot of transactions on some smal range of blocks and then use genblocks tools from darksidewalletd to create whatever we want to.

Describe the solution you'd like

The ideals would be just adding an extra enum on ZcashNetwork to actually represente regtest.

I've done a quick pass through the changes that would be needed to actually get this to the finish line.

Changes to ZcashLightClientKit / zcash-android-sdk

TreeState (aka Checkpoint) need to be decoupled from SDKSynchronizer so that they can be provided by another source for REGTEST. It is possible that API visibility can be leveraged so this API is only accessible through tests and never in production or release builds.

Make constants like saplingActivation have REGTEST variants as well or (better but larger change), refactor them so they are parameters and not constants.

Changes to zcash-light-client-ffi and zcash-android-sdk's ffi code

Add a Network::REGTEST network type constant on network-dependent APIs

Possible changes to Librustzcash (not sure if this is a must-do, or just a nice-to-have)

It seems that Network::Test and Network::REGTEST are used interchangeably in some places.
It would be desirable that this is not the case and that network is always specified explicitly.

Example:
In a glance when doing full-text search of the term REGTEST this code stands up
components/zcash_address/src/convert.rs

impl ToAddress for ZcashAddress {
    fn from_sprout(net: Network, data: sprout::Data) -> Self {
        ZcashAddress {
            net: if let Network::Regtest = net {
                Network::Test
            } else {
                net
            },
            kind: AddressKind::Sprout(data),
        }
    }

The ideal would be that each network has its own value and then its indistinct use is an implementation detail.

Alternatives you've considered

We originally thought Testnet was an alternetive but it doesn't have the flexibility and locality of Regtest

Additional context

This will allow the SDK to run tests like "Second Flush of Enthusiasm" from Zingo Labs which actually exercises a real use case of ZEC onboarding.

zingolabs/darksidewalletd-datasets#5