Implement clear rules for serializing keys in storage module.

[alekseysidorov]

Now we implicity that any types used as keys in storage table serialized to bytes in big endian order. But the trait for keys is AsRef<[u8]> which cannot provide proper flexibility.

See the PR for details.

[dj8yfo]

I don't understand the problem from description. Big endian - is fine for storage table keys (as much as i understand big endian helps lexicographically (@defuz) )close keys to be put to memory caches simultaneously by db queries).
trait StorageKey was proposed by @defuz for keys, and it has to use big endian, not implemented yet;
StorageValue (as of now both for keys and values) - for values, and it has to use little endian instead, so that ser/de number <-> StorageValue is a noop.

After a brief look at PR i assume we have to implement either:

1. StorageValue/StorageKey for (T,U), (T, U, Z), ... tuples of StorageValue. To do that we have to add field len() to the trait. And populate it correspondigly for structs generated by storage_value! (not with SIZE in the macro, because it can contain SegmentField). Supposedly not hard, just no one did that so far. But that'll be problematic for Vec<u8> type e.g. How do we know the size of Vec during deserialization without writing the size to the tuple serialized form? This overlaps with storage_value! functionality.

2. Use storage_value! for such composite types as (txid, validator, input_index) and all others.