v2 store UnorderedMap implementation

[austinabell]

As part of the revamp of collection types, I'll list the issues with the current version and how this new type will solve the issue.

Problems with near_sdk::collections::UnorderedMap:

• Removing a value from the map requires re-writing entries not touched by the operation
  • Create a new bucket type, which maintains indices on removals not to require updating
• There are two Vector types for the keys and values, which exaggerates the previous problem, but also requires multiple individual reads and writes
  • There will be one Bucket type, which is basically just a Vector to keep track of keys and leverage the feat: caching LookupMap implementation #487 impl
• API does not match standard Rust map types
  • feat: caching LookupMap implementation #487 Already does this, but UnorderedMap will allow other APIs such as iterators
• Inefficient for multiple access of the same key because it duplicates reads and deserializations
  • There are caching layers built into both inner data structures used already (Vector/Bucket(PR soon) and LookupMap)
• Uses storage manually to store the indices of each key to the index in each Vector, hard to maintain and open to bugs
  • Only uses LookupMap, and the value will contain the index for the bucket.

So the data structure will look something like this (visualized in JSONish):

Bucket: ["key0", "key2", "key1"]

LookupMap: {
  "<key0hash>": (<key0value>, 0),
  "<key1hash>": (<key1value>, 2),
  "<key2hash>": (<key2value>, 1),
}