refactor!: Refactor Community Pool Token Mechanics

[alexanderbez]

Description

This PR introduces the following changes to the way community pool tokens are managed:

• Turn the "fee pool" into an actual module account as opposed to a virtual account as it currently is
  • This allows anyone to send funds to the community pool by sending tokens directly to the module account
  • This also deprecates MsgFundCommunityPool
• Create a new message, MsgCommunityPoolSpend, that x/gov can execute via a proposal to spend community pool funds

Changelog

• Deprecate MsgFundCommunityPool
• Deprecate CommunityPoolSpendProposal
• Deprecate FeePool
• Remove legacy CommunityPoolSpendProposal x/gov v1beta handler
• Remove legacy CommunityPoolSpendProposal simulations
• Refactor the community pool to be a module account

TODO

• Migration
• Update docs
• Figure out where BlockedModuleAccountsOverride is defined and update it

closes: #12098

---

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)

[codecov]

Codecov Report

Merging #12831 (a77669c) into main (e39d84e) will increase coverage by 0.10%.
The diff coverage is 0.00%.

❗ Current head a77669c differs from pull request most recent head eafc55b. Consider uploading reports for the commit eafc55b to get more accurate results

@@            Coverage Diff             @@
##             main   #12831      +/-   ##
==========================================
+ Coverage   56.28%   56.38%   +0.10%     
==========================================
  Files         648      644       -4     
  Lines       55025    54759     -266     
==========================================
- Hits        30969    30878      -91     
+ Misses      21560    21391     -169     
+ Partials     2496     2490       -6     

Impacted Files	Coverage Δ
simapp/app.go	79.11% <ø> (ø)
x/distribution/client/cli/tx.go	6.49% <ø> (+2.36%)	⬆️
x/distribution/keeper/msg_server.go	18.26% <ø> (+2.82%)	⬆️
x/distribution/keeper/validator.go	92.20% <ø> (ø)
x/distribution/module.go	62.62% <0.00%> (-0.38%)	⬇️
x/distribution/simulation/operations.go	91.36% <ø> (+0.94%)	⬆️
x/distribution/types/codec.go	60.00% <ø> (+6.87%)	⬆️
x/distribution/types/msg.go	48.61% <ø> (-3.01%)	⬇️
x/distribution/types/proposal.go	0.00% <ø> (-6.90%)	⬇️
crypto/keys/internal/ecdsa/privkey.go	83.01% <0.00%> (+1.88%)	⬆️

[alexanderbez]

So unfortunately, after this approach I realized how intertwined the x/distribution module and it's account is with the community pool, which is a "virtual" account. This makes me lead to believe that my revised approach is also not viable.

Given, this I'm going to close the PR and instead do the following:

• Deprecate CommunityPoolSpendProposal
• Create MsgCommunityPoolSpend with x/gov as the authority (by default)