Tracking PR for ACL and capable data structures.

[JakeOShannessy]

We have a function ACL and some data structures implemented. I'm putting this into a draft PR so we can track progress. This PR tackles #123 and #183.

Some key items to complete:

• [x] Use a Cursor for reading and writing Storable*.
• [ ] ~Make Storable more robust in terms of size and type-safety.~

*Currently the storage serialisation mechansim (i.e. trait) for the types that are storable is distinct from the one used for capabilities etc. (kernel data) as they have slightly different requirements. It's quite likely that they could be merged, however, we should look at that only after this PR is complete.

[JakeOShannessy]

Functional aspects have been completed.

[JakeOShannessy]

• [x] Implement remove for StorageMap and StorageEnumerableMap`.
• [x] Implement pop for StorageVec.

The current implementation of StorageVec is quite simple, and removing elements would be prohibitively expensive (as the data is required to be contiguous), therefore remove will not be implemented. Given the characteristics of Ethereum storage, having a contiguous array of elements is not that beneficial, and so a more complicated vector that handles removal without copying might be feasible/desired.

[JakeOShannessy]

I've marked ready for review as it's probably better to start getting feedback at this stage than striving for perfection. I'd still like to improve some of the low level work, and there are some larger design questions how we treat Storable vs Serializable etc., but that's a long tail of smaller improvements. I feel those types of gradual improvements can be done in parallel with other higher-priority tasks,

[JakeOShannessy]

@Latrasis What are your thoughts on the mergability of this?

[Latrasis]

@Latrasis What are your thoughts on the mergability of this?

Sorry, didn't realize this was ready for review. I'll take a look