Allow SpendValidatingKey to be constructed from bytes

[pacu]

According to the FROST book the ASK is split using FROST and its verifying key is the ak that should be used to generate the Orchard Full Viewing Key.

Allow SpendValidatingKey to be constructed from bytes

closes #427

As we agreed with @daira at Z|ECC, this adds a FROST feature flag so that public interface of the crate is not altered in its meaning for non-FROST applications.

Key derivation is intended to be done on a specific way for usual applications. Interface changes introduce by FROST can pose a risk for the rest of the use cases that don't involve the assumptions of the FROST signature scheme protocol. we don't want non-FROST cases to make use the helper functions FROST needs to derive the needed key elements.

There are other changes pending to make FROST work with Orchard. Those changes will also be under this same feature flag

[str4d]

I'm fine with adding this kind of API behind an unstable cfg option, but I think that this API is not what we will want in the final production release, because I suspect we will not want people to pass around aks on their own (that will lead to partial loss of necessary details, and sadness).

To figure out the production API, we need to first finish the Key Generation part of ZIP 312. I'd started sketching that out in https://github.com/zcash/zips/pull/662#discussion_r1465663928 which I will move into a separate PR; once we've figured that out, we can provide higher-level APIs in this crate that produce the actual types we need.

[pacu]

I suspect we will not want people to pass around aks on their own (that will lead to partial loss of necessary details, and sadness).

Yes this is exactly what we don't want for non-FROST users.

@str4d, What about adding the visibility crate to handle the API changes as @conradoplg suggested?

We'd be adding #[cfg_attr(feature = "frost", visibility::make(pub))] but this is probably a dependency that is not feature-gated because it has to compile even when the frost feature is not selected

[str4d]

To figure out the production API, we need to first finish the Key Generation part of ZIP 312. I'd started sketching that out in zcash/zips#662 (comment) which I will move into a separate PR; once we've figured that out, we can provide higher-level APIs in this crate that produce the actual types we need.

I opened https://github.com/zcash/zips/pull/883 as that separate PR. @conradoplg @pacu let's figure out and specify the FROST-Orchard key tree interaction there.

[str4d]

According to the FROST book the ASK is split using FROST and its verifying key is the ak that should be used to generate the Orchard Full Viewing Key.

Just to be very clear here, the FROST book is not normative, except as it is incorporated by reference into the protocol spec or a ZIP (which to my knowledge it is currently not). It is very informative, but any FROST logic we put into the public crates needs to be tied to a normative reference. In this case, that is ZIP 312, so anything we do needs to be specified there (i.e. in the PR I linked above).