chore: Enforce order of store commits in root store

[catShaark]

Description

From what I read, LSM backend used by the sdk prefer the keys to be commited in ascending order. Right now, there's no logic enforcing the order of rootmulti.Store.stores and so when rootmulti.Store commit, we can't be sure that we're commiting the module stores in ascending order.

---

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...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• 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)

[yihuang]

Sort in loadVersion don't affect order in commit

[yihuang]

But it don't mean the nodes in iavl tree are written in key's order though.

[alexanderbez]

@yihuang or @tac0turtle can I get another approval here?

[julienrbrt]

@catShaark could you rebase? It'll automerge.

[faddat]

hi, @julienrbrt --

Sir, this is our best attempt at a rebase. The truth is, both Khanh and I are a little clueless when it comes to rebasing. I get that it is like "apply the differentialcommits to the branch I specify when I do" git rebase origin/main -- however:

1. could you please let us know if the above constitutes successful rebasing?
2. if rebasing isn't the thing I described above, would you mind having a call sometime for the purpose of our education? -- Khanh says that we can learn ourselves, but the truth is that Jacob has put >20 hours over the past 6ish months into trying to figure out rebasing, including the detailed reading of docs, the viewing of youtube videos, and such, and .... well, if that isn't a successful rebase, then we'd love some guidance :) <3.

[julienrbrt]

hi, @julienrbrt --

Sir, this is our best attempt at a rebase. The truth is, both Khanh and I are a little clueless when it comes to rebasing. I get that it is like "apply the differentialcommits to the branch I specify when I do" git rebase origin/main -- however:

1. could you please let us know if the above constitutes successful rebasing?
2. if rebasing isn't the thing I described above, would you mind having a call sometime for the purpose of our education? -- Khanh says that we can learn ourselves, but the truth is that Jacob has put >20 hours over the past 6ish months into trying to figure out rebasing, including the detailed reading of docs, the viewing of youtube videos, and such, and .... well, if that isn't a successful rebase, then we'd love some guidance :) <3.

It was :) rebase or merge does not really matter for PR anyway. I just meant syncing with main because the branch was out of date. If you still need some guidance, feel free to reach me on discord/slack.