refactor!: Make store its own go module

[ValarDragon]

Description

This PR makes store its own package. I consider this to be one of the biggest things for shared iteration & feedback loops on this part of the stack. In particular, we could test store updates much more easily within the osmosis repo, and contribute them upstream /' swap between versions much easier, than the current UX via our fork.

Please feel free to close if this interferes with existing plans. However, I would really love if this could make it into SDK release soon. (I'm personally very in favor of making a non-state breaking minor SDK release)

I'm happy to add example upgrading docs in a file if someone points me where, and agrees this is the right approach. (Plus if I'm not interfering with existing plans atm!)

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

I have...

• [x] included the correct type prefix in the PR title
• [x] added ! to the type prefix if API or client breaking change
• [x] targeted the correct branch (see PR Targeting)
• [ ] provided a link to the relevant issue or specification
• [x] followed the guidelines for building modules
• [x] included the necessary unit and integration tests
• [ ] added a changelog entry to CHANGELOG.md
• [x] included comments for documenting Go code
• [ ] updated the relevant documentation or specification
• [ ] reviewed "Files changed" and left comments if necessary
• [ ] confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

I have...

• [ ] confirmed the correct type prefix in the PR title
• [ ] confirmed ! in the type prefix if API or client breaking change
• [ ] confirmed all author checklist items have been addressed
• [ ] reviewed state machine logic
• [ ] reviewed API design and naming
• [ ] reviewed documentation is accurate
• [ ] reviewed tests and test coverage
• [ ] manually tested (if applicable)

[ValarDragon]

Hrmm, several tests are failing due to API rate limits? Could an admin check in on that / re-run when they get a chance? I imagine its applying to all PR's rn

[ValarDragon]

ack for changing the module import path!

Disagree for it not changing anything in terms of dependencies, this is on its own quite useful even under the current API, of enabling releases of store on its own that can be easily imported across cosmos.

Re: API bleed, I think a lot it can be fixed in subsequent versions, but we can iterate on this so much faster if changes can get into live chains without significant version bumps.

Obviously the judgement on how much to do prior to an initial release depends on the amount of work to clean up API's once, which you have more insight than I do on. I am pretty happy to close and follow along your plan! (Though I do really like getting to an initial separate mod sooner)

[faddat]

Hi everyone, I spotted this PR a few days ago, and I consider it to be way better than updating the osmosis-labs/tm-db to include changes that are already present in cosmos-db.

I'm going to peek more here, because it is just a better solution and means that we will collaborate more here, on this repository.

[tac0turtle]

closing this, as I need to submit a pr cleaning up the conflicts, but we can spin the store module out now. There is one dep on base app we need to clean up but I don't think this is a blocker