Re-export ibc-relayer-types used in env

[Kayanski]

This PR aims at re-exporting the ibc-relayer-types needed inside cw-orch-interchain::env. This allows users to not import ibc-relayer-types crate when integrating and using cw-orch-interchain

Checklist

• [x] Changelog updated.
• [x] Docs updated.

[cloudflare-pages[bot]]

Deploying cw-orchestrator with    Cloudflare Pages

Latest commit:	8547823
Status:	✅  Deploy successful!
Preview URL:	https://7d8e9db5.cw-orchestrator.pages.dev
Branch Preview URL:	https://nicolas-orc-145-re-export-ib.cw-orchestrator.pages.dev

View logs

[CyberHoward]

How often are those types used?

[Buckram123]

How often are those types used?

Create channel requires PortId. I'm not a huge fan of "portid".parse().unwrap() as it's not very clear to which type it's getting parsed and it's the only way to not re-export same version of ibc-relayer-types

[CyberHoward]

I don't understand. This crate will also be included in wasm build (it's not wasm featured).

And even then I'm unsure about whether this is needed. Can we accept in Into<String> for that fn and parse internally instead?

[Buckram123]

And even then I'm unsure about whether this is needed. Can we accept in Into<String> for that fn and parse internally instead?

PortId have few helpful infallible creation method like commonly used PortId::transfer(). I'm ok to take AsRef<str> and parse it internally as well!

[Kayanski]

I don't understand. This crate will also be included in wasm build (it's not wasm featured).

And even then I'm unsure about whether this is needed. Can we accept in Into<String> for that fn and parse internally instead?

This is possible yes. We have discussed about variables naming and I think that those types come in handy. We could also get rid of them, but that would make the API less clear as well.

In another topic, I made the dependency wasm protected