Refactor ivk types to make "zero" unrepresentable

[str4d]

Currently when parsing e.g. a Sapling diversifiable IVK from a UIVK, we check that the ivk portion is canonical, but it may be zero: https://github.com/zcash/sapling-crypto/blob/6a8282be0959b410a0b622cd5eb84f8c3c134078/src/zip32.rs#L850-L860

The protocol spec requires that pk_d is not the identity, implying that both g_d is not the identity, and ivk != 0. We enforce this in the construction of PaymentAddress: https://github.com/zcash/sapling-crypto/blob/6a8282be0959b410a0b622cd5eb84f8c3c134078/src/keys.rs#L432-L437 https://github.com/zcash/sapling-crypto/blob/6a8282be0959b410a0b622cd5eb84f8c3c134078/src/address.rs#L28-L55

However, after https://github.com/zcash/zips/pull/672 the protocol spec also requires that ivk != 0. This makes sense because ivk = 0 is useless due to having no addresses, and thus even if we assume that someone hit the $2^{-256}$ chance of deriving a spending key with ivk = 0, they cannot have put funds into it.

We should perform this refactor, which will move the fallible step to IVK parsing, and thus the ivk-to-address derivation APIs could then be made infallible.