POC module wiring with uber-go dig

[aaronc]

Description

Module wiring using uber's dig dependency injection container.

There are two approaches to module wiring demonstrated here:

• the Provide* method approach, see https://github.com/cosmos/cosmos-sdk/blob/aaronc/minimal-di-wiring-v3/x/auth/module/module.go. In this approach, all Provide* methods are used in the dependency injection container automatically with ModuleKey being a special parameter.
• the Provisioner interface approach, see: https://github.com/cosmos/cosmos-sdk/blob/aaronc/minimal-di-wiring-v3/x/gov/module/module.go. In this approach, Provision is called with a ModuleKey and a container.Option is returned. container.Option is inspired by uber-go/fx: https://pkg.go.dev/go.uber.org/fx#Option, and it's a nicer way to compose things than using dig.Provide directly.

I think I pretty strongly prefer the first Provide* method approach for most module development because it just looks cleaner to my eyes. (Also it could be amenable to static analysis a la google/wire in the future but I'm not even sure it's worth it at this point.) I do think the fx Option approach is good for lower-level "non-module" providers.

---

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)