Implement new address format

[ghost]

Addresses now must commit to VPs, so we must distinguish between old-style public key addresses (which we are also keeping, but only have meaning inside of VPs) and new-style VP addresses.

• [x] Implement new Address types and functions in Rust
• [x] Update Note type to use new address
• [ ] Add com_vp as public input and check it against address field in Note
• [ ] Decide on commitment scheme to use for com_vp (initially, let com_vp be transparent), such as BLAKE2s (overlaps with heliaxdev/pbc#1)
• [x] Implement out-of-circuit checking a PLONK circuit against an address
• [ ] Support "short" receiving addresses with default VPs heliaxdev/pbc-playground#7
• [x] Document address format in spec
• [x] Make new address tests

There is a special case to handle of mutually-self-referential addresses. This does not appear to require any protocol level or address format changes, but rather is a VP implementation task (#2)

[ghost]

Each address in Taiga is used in two places, spending:

1. The address is contained in each Note commitment (either as a user, or token, address) which commits to at least the spending VP.
2. The address is used by a transaction builder to create Notes with that user or token address by proving that address's receiving VP.

For example, suppose Alice builds a transaction that creates Notes that belong to Bob. These new notes contain Bob's address (and the token address). Alice also needs to prove Bob's receiving VP. So Alice must know:

1. A hiding commitment to Bob's spending VP, to put in the new notes
2. Actual knowledge of Bob's receiving VP circuit, to authorize the creation of the new notes

Therefore the desired requirements for the address format are (roughly):

1. The address includes a binding commitment to the sending VP, nullifier key, and receiving VP.
2. The receiving VP commitment can be opened separately from the sending VP (and nullifier key). This is so that the Alice can send notes to Bob's address (using Bob's receiving VP) while Bob's sending VP remains hidden from Alice.
3. The address must include enough details so the sender can prove the receiving VP (this may make the address extremely large)
4. The default receive VP cases (e.g. receive all-allowed) should have short addresses, probably special-cased. This might require a set of receive VPs built into the wallet.
5. The addresses must be easily re-randomizable for unlinkability between addresses with the same spending VP. Since the receiving VP must be known to the sender, unlinkability must be at the transaction level.
6. Support for self-referential and mutually-referential addresses. This is nontrivial, but mostly necessary, because a VP may transfer assets temporarily to another VP, to be returned later.
7. Only the owner of the sending VP can derive new addresses with this sending VP

This last property may not be possible to achieve (and is not achieved by the current design). The sender may substitute any receiving VP they want and construct a new address with the existing spending VP, and the new receiving VP. So receiving VPs are essentially useless currently.

[XuyangSong]

Some above descriptions and tasks are done, and some need to be updated. But we might still need the new address format design. The address-relative fields are nullifier_key_commitment, app_data_dynamic, viewing key(note encryption), and other potential data. #132 #123