Design Issues with loamstorage

[willemneal]

Having ported over all examples to use loamstorage several issues came up.

• Allow for tuple structs, e.g. struct Storage(Address, u32) instead of requiring named fields. This will mean that the key can be a u32 instead of the full text of the field. A cost savings for any field name with a length > 4.
• Allow for specificing the key as a macro #[with_key(..)]`. This is a rare case, but should be supported.
• Make a special case for single value structs. E.g. Storage(Address). While it works it's not ideal to do self.0.get(). It would be nice if it worked similarly to how it worked before.

A big one that is another issue which much be handled by derive_contract and subcontract is handling constructors. For Items, for a simple refactor, I did .get().unwrap all over the place. Ideally there should be a standard way to ensure that these items are initialized so that the can be loaded for the dev or .get should not return an option. And there should a standard error for initialized subcontracts. For example requiring a #[init] the the method generated by derive_contract will handle loading in the inner item if it's a single struct.

One thing I will say about the current design is that it is explicit, mostly hiding key names. So more magic might not be too helpful, but the tuple struct is a definite cost saver.