Design and implement RawVec and RawHashMap

[Robbepop]

Design: RawVec and RawHashMap

This issue tracks design decisions around RawVec and RawHashMap implementations.

Problem

The current storage::Vec and storage::HashMap are very different from their counterparts (dynarray and mapping) in Solidity. They are targeted for a higher level of abstraction and provide more guarantees to the user.

The Solidity types are bare-metal, provide nearly no guarantees to the user and are targeted more towards efficiency and performance. Even though the Solidity types are arguably less secure and should be avoided for those reasons to write smart contracts in general, they might still be of some use for very experienced smart contract writers.

[Robbepop]

In the presence of storage fees these low-level abstractions might be very user unfriendly since the users would need to do lots of manual management around those data structures. All in all they should generally be avoided. Yet there might be use-cases. We shall implement this as soon as someone finds a suitable use-case that cannot be efficiently supported by the currently existing abstractions and utilities.

[Robbepop]

Superseeded by newer ideas around storage::HashMap to make it aware of its keys and also let it work similar to Solidity-mappings. Closed.

Also: #347