Refactor: Unify DomainAddress and account conversions (r2)

[lemunozm]

This PRs overwrites https://github.com/centrifuge/centrifuge-chain/pull/1967

Description

Represents DomainAddress as:

enum DomainAddress {
    Centrifuge(AccountId32),
    Evm(EVMChainId, H160),
}

With some utility methods as:

fn account() -> AccountId32;
fn h160() -> H160;
fn bytes() -> [u8; 32];

Main changes

• Removed account conversions through Convert traits. Now DomainAddress knows how to convert accounts.
• Unify [u8; 20] to [u8;32] conversions. See this slack thread
• Renamed EVM to Evm (following rust guidelines)
• (only in IT). Removed From/Into traits from Keyring to H160 and [u8;20] and use instead an explicit method called in_eth() (open to name proposals). This method represents the account in the Ethereum network. Note that this differs from Keyring::Alice.into()[0..20], which is used in other places where an Ethereum account is stored as an AccountId and needs to be recovered. Because this is highly confusing, I've removed the into/from methods to be more explicit about when the first case happens.

[lemunozm]

@wischli @cdamian I tried my best from your inputs in the other PR. I would really love to have types who knows about conversions but it's quite tedious for Monday (we also will need implement them with a lot of traits, etc).

I think this solution leaves things easier than before, but of course, it still can be improved with more sophisticated solutions.

Let me know if you agree more with the names than the before PR.

[lemunozm]

As for the naming of fn bytes(), I am not 100% on board

I wanted to not use address because it's quite generic, could be not just an array, and for that method we're specifying that we want the account as an array of bytes.

Rust names *_bytes() to actions that return an array, but I am open to other names, I can do it in a next PR if needed

[lemunozm]

I'm very happy to have this PR before the audit! 🎉