Fix Dockerfile build issues.

[DimitrisJim]

Description

Mirrors the Dockerfile currently used for wasmd. Based on alpine, grabs the static library for libwasm and builds ibc-go with it. Ideally most of these can be plucked and used in main beforehand but opening this first.

closes: #XXXX

Commit Message / Changelog Entry

type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md).
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/) or specification (x/<module>/spec/).
• Added relevant godoc comments.
• Provide a commit message to be used for the changelog entry in the PR description for review.
• Re-reviewed Files changed in the Github PR explorer.
• Review Codecov Report in the comment section below once CI passes.

[DimitrisJim]

ideally #4067 goes first to main, then can rebase this once it is included in base branch.

[DimitrisJim]

Some more context. Statically linking is not necessary, we could also do dynamic linking here and just grab the .so libs from wasmvm's internal/api folder (this is how I did it in the now closed PR). That is generally a bit cleaner since we don't need to reference the specific version of libwasmvm to download (i.e, we download 1.2.1 here to match what we have in our go.mod).

The downside is that, since we use multi-stage builds, any shared libraries we reference in the first stage of the build (on the builder image) must be copied over. We could also have a similar situations with other shared libs in the future. (I.e we'd need an additional COPY --from=builder shared/lib/path to reference them).

I don't particularly think it makes sense to use shared libraries in a docker image that won't have many components actually sharing the libraries but I don't have that strong of an opinion on it.

[crodriguezvega]

🥇