imp(osmosis-outpost): Make the input to the swap function a struct and refactor tests

[Vvaradinov]

Description

---

This PR creates a struct type for the Osmosis outpost input params to keep the validation and parsing cleaner. It also implements the Outpost Client Arguments ADR by passing extra params like channelID and XCSContract.

Closes XAP-10

[codecov]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (05eea03) 70.54% compared to head (1b5656c) 70.47%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2206      +/-   ##
==========================================
- Coverage   70.54%   70.47%   -0.07%     
==========================================
  Files         291      291              
  Lines       22672    22629      -43     
==========================================
- Hits        15993    15947      -46     
- Misses       5807     5809       +2     
- Partials      872      873       +1     

Files	Coverage Δ
precompiles/outposts/osmosis/osmosis.go	34.92% <100.00%> (-6.51%)	⬇️
precompiles/outposts/osmosis/tx.go	83.92% <100.00%> (ø)
x/evm/keeper/precompiles.go	82.11% <100.00%> (-0.97%)	⬇️
precompiles/outposts/osmosis/types.go	82.96% <63.63%> (-4.85%)	⬇️

[0xstepit]

I like the approach of reducing the number of inputs in functions but to be honest I don't see any advantage in doing it in this case. We should avoid >2/3 inputs in internal functions because it will make maintainability easier and the code cleaner. But, what is the purpose of using a struct to group all inputs from the user API like a contract? The user should pass the same number of params AND group them in a struct.

[Vvaradinov]

@0xstepit I was researching this and the recommendation I am making is to keep it a struct due to Solidity structs being packed thus providing more efficiency for direct calls which is what I believe will the majority of calls for the Outpost. reference

[GAtom22]

we'll need to remove the wevmos logic from the nix tests here to avoid getting error. Similarly to how we did it on the release/v16 branch. The thing is that we removed the registerCoin proposal from main. That's what the error is about.

I guess we'll need a wevmos address from genesis according to the logic we have now.

[Vvaradinov]

@GAtom22 since we were merging to the release branch directly the logic is not here, but I think we should merge back and make the main branch up to date before merging it to the release branch.

[linear]

XAP-10 Client side Params (ADR)

[GAtom22]

LGTM! Great work @Vvaradinov!!