Address space unification.

Given recent development of 2.0 and new VM, I noticed that long awaited address space unification is not really happening... Let me unpack that.

Currently Casper offers three different address spaces:
- Account Hash - represents an account,
- Contract Hash - represents a single contract version,
- Contract Package Hash - represents a pack of Contract Hashes that (mostly) share the same storage.

We have learned that using Contract Hashes to represent the contract in another contracts is not a good idea. It's simply not practical. Consider following scenario:
- There is a (CEP18/ERC20) token contract that hold token balances for accounts and contracts.
- There is another contract with Contract Hash `0xVersion1` and Package Hash `0xPackage`.
- If Contract Hash is used as a balance key, then in token contract would has a record in a balances dictionary: `0xVersion1 -> 100`.
- Now if contract is buggy or simply needs an upgrade, then it would be replaced with a new version `0xVersion2`.
- But the data in the token contract points to `0xVersion1`, so tokens are not accessible to `0xVersion2`, and require a migration, which is not always possible, expensive and wrong architecture in general.

The solution is to use Contract Package Hash as a key. This way balance key is `0xPackage -> 100` and even after an upgrade of the contract, tokens are accessible. This is why CEP18 uses `Key` to represent an address.

What I expected in terms of address space unification in 2.0 is that Account Hashes and Contract Package Hashes would be unified under a single type. Instead Account Hashes and Contract Hashes are unified under a single type (EntityHash), and Contract Package Hashes are left as they were.

I think this is missed opportunity for solving actual problem.