Introducing appmodule in depinject breaks compatibility

[julienrbrt]

In #19010 I was testing the packages' compatibility with previous SDK versions and noticed that due to depinject importing api in its appmodule package, a simple bump in v0.47 won't immediately work.

(release/v0.47.x {2} ✓) simapp go mod tidy
go: downloading cosmossdk.io/depinject v1.0.0-alpha.4.0.20240110165557-1e7611faab88
go: finding module for package github.com/cosmos/cosmos-proto/any
go: finding module for package cosmossdk.io/api/cosmos/capability/module/v1
go: cosmossdk.io/simapp imports
        cosmossdk.io/api/cosmos/capability/module/v1: module cosmossdk.io/api@latest found (v0.7.2), but does not contain package cosmossdk.io/api/cosmos/capability/module/v1
go: cosmossdk.io/simapp imports
        cosmossdk.io/core/appconfig imports
        github.com/cosmos/cosmos-proto/any: module github.com/cosmos/cosmos-proto@latest found (v1.0.0-beta.3), but does not contain package github.com/cosmos/cosmos-proto/any

A user upgrading to the latest depinject version and using v0.47.x would need to add the following in its go.mod:

replace (
	cosmossdk.io/api => cosmossdk.io/api v0.3.1
	github.com/cosmos/cosmos-proto => github.com/cosmos/cosmos-proto v1.0.0-beta.2
        golang.org/x/exp => golang.org/x/exp v0.0.0-20230711153332-06a737ee72cb
)

Proposed solutions

• Move depinject/appmodule somewhere else
  or
• Create a compatibility matrix for depinject (I am personally quite against that)
  or
• Accept that users need to add the following replace statement and document it

This issue can serve of document if we proceed with it, but I thought this was something important to note.
For that reason, I haven't tagged depinject after #19010.

[julienrbrt]

We have fixed the api module compatibility thanks to cosmos-proto and we added the golang.org/x/exp replace in the sdk as it will always get bumped.