Secondary indexes support

[ethanfrey]

Closes #468

Merge #559 first, then I will rebase on top.

This is a work in four steps

1. allow exactly 1 secondary index, no multi-prefix on primary key
2. allow multiple named secondary indexes, no multi-prefix on primary key
3. add support for unique indexes
4. allow multiple named secondary indexes, clean composite key support

All are now done (4th was done in #558 as a side-effect of re-using bucket code)

• Create one secondary index
• Create multiple secondary indexes
• Basic write/query tests
• Basic update/remove tests
• Revise API design
• Add unique indexes
• Add ReadOnlyIndexedBucket (Not needed if Keep Storage external to Bucket #559 is merged)
• Better unit test coverage
• Improve docstrings
• Update CHANGELOG
• Update MIGRATING
• Update README - revise with Merge Core and Bucket #558 and Keep Storage external to Bucket #559 as well

Update:

As part of an attempt to make ReadOnlyIndexedBucket, I came across the annoyance that Bucket and ReadonlyBucket are different types, but only based on the mutabilty of the storage object. If we didn't store that, we could have one class that just took methods that were either &Storage or &mut Storage. And this would improve composition.

For PrefixedStorage, I see the desire to have the Storage object inside (this is a separate wrapper), but for the more complex cases that do not implement Storage themselves, this seems much overhead. I made PR #559 to implement this (on master, independent of the secondary index work)

[ethanfrey]

This is in a mostly-working state to show an approach to automatic indexing as a new bucket type. I would love some feedback on the design and API, as well as any implementation improvements you see - this is obviously a rough implementation, but point out any larger issues you see. Ways to simplify, optimize, or missing functionality.

@orkunkl you worked a lot with the weave orm, I'd love your opinion on API design here from that experience

[ethanfrey]

After discussion, I will not continue this in cosmwasm, and not modify Bucket, but build the new structures with new names in cosmwasm-plus. We can extend cosmwasm-storage later when they are stable, but for now, let's keep it stable.

Leaving this PR until all logic has been moved to cosmwasm-plus

[ethanfrey]

This has been done in https://github.com/CosmWasm/cosmwasm-plus in the cw-storage-plus package (in various PRs building on #108)