feat: add interchaintest package that runs E2E tests for LSM and x/gov

[xlab]

Hey there, adding a self-contained interchaintest suite with two LSM-targeted tests. Both just playing with tokenization and redemption of users delegations while making votes on a proposal, to verify that nothing weird happens in the tally due to liquid shares. Later this can be expanded to include some real IBC testing as well.

I don't know what's the best place to PR this suite - should it be gaiad or simd, so pushing right there. This test suite is self-contained and oriented towards SDK v0.45.

How to run

1. Build the simd docker image from the repo root

cd cosmos-sdk-iqlusion/
docker build -t simd:local .

2. Run the test suite

cd interchaintest/
go test -v ./...

If everything works fine, both tests will finish in parallel in about 1m30s:

ok  	github.com/cosmos/cosmos-sdk/interchaintest	93.253s

Description of tests

TestTokenizeSendVote

TestTokenizeSendVote checks that once shares are tokenized, the tokens can be sent to other party and used for voting, however, not counted in tally until bonded.

1. Create a single chain instance with 4 validators
2. Allocate two chain users with funds
3. Bond 100000stake first user
4. Tokenize 100% first user
5. Send 1stake tokenized from the first user to second user
6. Submit a proposal from second user
7. Second user votes Yes - his vote is not reflected in tally
8. Second user redeems 100% - his vote now reflected in tally
9. Second user tokenizes 100% - his vote is removed from tally
10. First user votes NoWithVeto - his vote not reflected in tally
11. First user redeems remaining 99999stake - his vote reflected in tally towards NoWithVeto
12. Second user redeems 100% - his vote also reflected in tally towards Yes

TestMultiTokenizeVote

TestMultiTokenizeVote case checks what happens with a voting tally when two separate LSM users are tokenizing and voting independently. This case might look very similar to previous one, but the difference is that no shares are being sent, both users are tokenizing independetly.

1. Create a single chain instance with 4 validators
2. Allocate two chain users with funds
3. Bond 100000stake first user
4. Bond 1stake second user
5. Tokenize 100% shares second user
6. Submit a proposal from second user
7. Second user votes Yes - his vote is not reflected in tally
8. Redeem 100% shares second user - his vote is now reflected in tally
9. First user votes NoWithVeto - his vote is reflected in tally
10. Tokenize 100% shares first user - his vote is removed from the tally
11. No votes displayed in the voting tally as both delegators have tokenized their shares
12. Redeem 100% liquid tokens first user - his vote reflected in tally towards NoWithVeto
13. Redeem 100% liquid tokens second user - his vote also reflected in tally towards Yes

[xlab]

An additional test is brewing up that tests validator-bond effects:
persistenceOne/persistenceCore#225

Quite useful for modelling high-level chain interactions