[Feature Request] TypeTable

# 🚀 Feature Request

## Motivation

I have mentioned the idea of TypeTable in the documentation of Table, and I describe it in more detail here.

According to the implementation of Table(#150), we get:

```rust
module Std::Table {
native struct Table has store;
native fun create(): Table
native fun destroy(t: Table);
native fun insert(t: &mut Table, k: &K, v: V);
native fun remove(t: &mut Table, k: &K): V;
native fun contains_key(t: &Table, k: &K): bool;
native fun borrow(t: &Table, k: &K): &V;
native fun borrow_mut(t: &mut Table, k: &K): &mut V;
}

```

But this Table can only use type K's value as the key, not type K as the key like borrow_global.

So I suggest introducing TypeTable with the basic operations described below:

```rust
module Std::TypeTable {
native struct TypeTable has store;
native fun create(): TypeTable
native fun destroy(t: TypeTable);
native fun insert(t: &mut TypeTable, v: T);
native fun remove(t: &mut TypeTable): T;
native fun contains_key(t: &TypeTable): bool;
native fun borrow(t: &TypeTable): &T;
native fun borrow_mut(t: &mut TypeTable): &mut T;
}
```

Now, we can define a AccountStorage struct in Move:

```rust
module Std::Account{
struct AccountStroage{
resources: TypeTable,
moudles: Table>,
}
}
```

Then we bind the table when Account create, such as:

```rust
module Std::Account{
public fun create_account(addr: address){
let resources = TypeTable::create();
let modules = Table::create>();
let account_storage = AccountStorage{
resources,
modules,
};
native_save_account(addr,account_storage);
}

public fun borrow(addr:address):&T{
let account_storage = native_get_account_staroge(addr);
//This expression is not available in the current Move
//We can not return ref like this, but we can ignore it now.
return TypeTable::borrow(&account_storage.resources);
}

public fun move_to(signer:&signer, t:T){
//if do not want to limit signer, can use address.
let addr = Signer:address_of(signer);
let account_storage = native_get_account_staroge(addr);
TypeTable::insert(&mut account_storage.resources,t);
}

//We can update or deploy code in Move now, like `create2` in ethereum.
public fun update_module(signer:&signer, name:Identifer, code:vector){
let account_storage = native_get_account_staroge(addr);
account_storage.modules.insert(name, code);
}
}
```

* Now, borrow_global(address) = Account::borrow(address),
and move_to(siger) = Account::move_to(siger), global_storage operation can been eliminate.
* The transaction ChangeSet are all table_changes.
* Every Move chain framework can customize their own account storage via the TypeTable and native function.

This feature can implement via an extension like Table and the backend storage is the same as Table, but TypeTable needs the same security guarantees as borrow_global.

We have two approaches to achieving this goal:

1. Introduce TypeTable into core instead of extension, add security restrictions to TypeTable::borrow similar to borrow_global.
2. Introduce the visibility of Struct and let the smart contract developer can control the access of Struct, see issue #157.

Begin with the Table implementation referenced by issue #150 and compare its extension and backend-storage approach with the proposed TypeTable API. Review issue #157 and the two listed design approaches before deciding whether this belongs in core or an extension. Done means the TypeTable operations and their security guarantees are specified well enough to support the intended account-storage model.

Written by the indexing model from the issue text.