feat: add begin and end blocker support to module/server

[robert-zaremba]

Description

Closes: #689

Initially I started implementing begin and end blocker support through new Configurator register functions (similarly to `RegisterGenesisHandlers). However this approach has downsides:

• it hides modules, so it's not possible to customize the execution order
• it further away from the SDK design
• would require yet another small rework of the ecocredit Module by removing the keeper and moving the whole logic to the keeper itself (the server) - which is mixing module logic with the data and execution layer.

So, instead I added Begin and End blocker functions to the Regen module/server.Module, which uses modules directly to execute the begin / end blockers.
I had to update the module to be mutable - the keeper assignment in RegisterServices wouldn't work otherwise.

---

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)

[robert-zaremba]

Pointer receiver is required to handle keeper registration in RegisterServices

[aaronc]

It doesn't seem like this does any particular ordering, other than registration order which is deterministic. Maybe that's okay since it's a short term fix. It would be good to actually make ecocredit have a begin and end blocker even if they don't do anything yet.

[robert-zaremba]

@aaronc x/ecocredit has a registered Begin Blocker (in this PR). It doesn't have end blocker. I can add an empty one.

Maybe that's okay since it's a short term fix.

I don't think we need it (there is only one module, and even with cosmowasm, registration order will work good enough). Once we will Cosmos SDK 0.46 we should migrate to AppModule

[aaronc]

the simulation issue does seem to be related to the ecocredit begin blocker

[technicallyty]

could you add a test for these changes?

[aleem1314]

@robert-zaremba I think simulations are failing because of duplicate prefixes for orm tables.

[codecov]

Codecov Report

Merging #720 (94f9064) into master (3948500) will increase coverage by 0.04%.
The diff coverage is 55.88%.

❗ Current head 94f9064 differs from pull request most recent head 61b80ed. Consider uploading reports for the commit 61b80ed to get more accurate results

@@            Coverage Diff             @@
##           master     #720      +/-   ##
==========================================
+ Coverage   40.25%   40.30%   +0.04%     
==========================================
  Files         124      124              
  Lines       37215    37246      +31     
==========================================
+ Hits        14981    15012      +31     
+ Misses      21266    21258       -8     
- Partials      968      976       +8     

Flag	Coverage Δ
experimental-codecov	40.23% <55.88%> (+0.01%)	⬆️
stable-codecov	34.42% <55.88%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[ryanchristo]

Looks good to me. One question. Pre-approving.

[aaronc]

LGTM. But there are some unrelated changes that need to be reverted. Once that's done ready to approve

[aaronc]

approving as @robert-zaremba clarified that the changes to store key prefixes are to fix conflicts introduced in #647