Rework Namada addresses

[sug0]

Context

All Namada addresses (established, implicit and internal) are currently encoded with bech32m, with an atest prefix. The data being encoded for these addresses consists of 45 bytes, split into the following sections:

• A 3 byte prefix (e.g. "nam")
• Two colon characters ("::")
• 40 bytes of arbitrary data (e.g. for implicit addresses, this will be a hex encoded truncated public key hash)

A consequence of this is that we employ some hacks for internal addresses, to fit the criteria above. See:

mod internal {
    pub const POS: &str = 
        "ano::Proof of Stake                          ";
    pub const POS_SLASH_POOL: &str =
        "ano::Proof of Stake Slash Pool               ";
    pub const PARAMETERS: &str =
        "ano::Protocol Parameters                     ";
    pub const GOVERNANCE: &str =
        "ano::Governance                              ";
    pub const IBC: &str =
        "ibc::Inter-Blockchain Communication          ";
    pub const ETH_BRIDGE: &str =
        "ano::ETH Bridge Address                      ";
    pub const ETH_BRIDGE_POOL: &str =
        "ano::ETH Bridge Pool Address                 ";
    pub const REPLAY_PROTECTION: &str =
        "ano::Replay Protection                       ";
    pub const MULTITOKEN: &str =
        "ano::Multitoken                              ";
    pub const PGF: &str =
        "ano::Pgf                                     ";
}

Goal

We should introduce different prefixes, for addresses with different size constraints.

• Transparent addresses (whether implicit or established) should use a tnam prefix. A discriminant byte (e.g. with a value of 0/1) may be used to distinguish between implicit or established addresses, followed by the raw (truncated to 20 bytes) public key hash of an address, in the case of implicit addresses, or random data, in the case of established addresses. This will result in encodings of the form: tnam1xqqqzqsrqszsvpcgpy9qkrqdpc83qygjzvd4tm66. Maybe established/implicit keys should have different bech32m prefixes?
• Shielded addresses should use a znam prefix. See section 5.6 starting on page 110 of the zcash paper for size constraints. Distinguishing between different MASP keys may also be done with a discriminant byte. Perhaps we should use a different prefix for these?
• Other prefixes should be chosen for internal addresses, such as ERC20 wrapped assets, the Ethereum Bridge pool address, etc.

[sug0]

Depends on #1840

[tzemanovic]

related issue #112