Zebra: reorganize zebra-chain sprout/sapling types

[yaahc]

Right now in zebra-chain for notes, addresses, keys, and similar types we export a module for the data kind and then internally we have a sprout.rs and a sapling.rs module for each specific implementation of that outer module kind.

This organization structure introduces name conflicts by having many more potential name conflicts than the alternative, which is to have a single outer modules for sprout and sappling and inner modules for each specific implementation for keys and what not. For example, I went to introduce crate::nullifier::sprout::Nullifier to a new module but could not shorten the name to sprout::Nullifier because sprout was already in-scope from a use crate::notes::sprout;.

[hdevalence]

This seems like it could be a good idea. One point to consider is that most users will only want to work with Sapling, so having a top level distinction between Sprout and Sapling could be convenient for them.

[yaahc]

@dconnolly did you already do this one as part of your note commitments change?

[dconnolly]

@dconnolly did you already do this one as part of your note commitments change?

No, this item will happen after that is merged, since it's already touching 30+ files