feat: collections API

[testinginprod]

Description

Introduces the unified state layer

Purpose

Makes state handlings things easier and safer and standardized.
closes: #895

[testinginprod]

please don't merge master as of now in this branch ty.

[NibiruHeisenberg]

Isn't this Insert redundant since kv("a") creates the obj already?

[NibiruHeisenberg]

I'm not sure if we want to support other iteration patterns (e.g. like random access) since they are non-deterministic. I would consider if a boolean for AccessOrder is simpler than an iota. Something like true = ascending, false = descending.

[testinginprod]

Yes the intention is to have only two iteration orders. It's just that in go there are no enums, and having booleans in constants that work like enums is not common, so I went for u8 which is the smallest value.

[testinginprod]

IDK if @AgentSmithMatrix has some other feedback.

[testinginprod]

@NibiruHeisenberg , @AgentSmithMatrix there's also another point that I would like to understand before merging this. A lot of Mapping methods want to map primitive types:

• StringKey => uint64
• StringKey => string.

Currently the only way to do this is to use prototypes BytesValue StringValue etc.

Which make setting/getting/using the values verbose ex: m.Insert(ctx, key, gogotypes.Uint64Value{Value: 0})

For the sake of simplification we can:

• make StringKey/Uint64Key/etc implement Object which makes them valid values for Map and Item.
• create a secondary package (wellknown or values) which contains those types.