feat: support direct ESM imports in wasm

[brendandahl]

Directly import from an ES module following the ESM integration proposal.

e.g.

(import "./add-esmi-deps.mjs" "getValue" (func $getValue (result i32)))

This adds wabt as a dependency to build the test example and test case .wat file.

resolves #54

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.69%. Comparing base (67a94a9) to head (69036f5).
Report is 23 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
- Coverage   90.80%   88.69%   -2.11%     
==========================================
  Files           6        8       +2     
  Lines         500      336     -164     
  Branches       53       68      +15     
==========================================
- Hits          454      298     -156     
+ Misses         45       38       -7     
+ Partials        1        0       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pi0]

Perhaps we could use esm resolution to support node_modules and import maps and also fail if ESM import in wasm cannot be resolved?

(we can use exsolve for this)

[brendandahl]

Nice, I'll switch to that.

There's currently the path where imports don't have to be resolved (e.g. resolved = false). If we error out I think we'll break that. Do we want a mode where imports have to be resolved or is there some other way you are thinking we should implement that?

[pi0]

We could use exsolve.resolve(id, { try: true }. Is there a case that non resolvable ids might be safe?

[brendandahl]

You could have a non-resolved id and then supply it in the imports. e.g.
importObj = { 'someFile.js': { foo: ....} }. I don't know how useful this feature is though. I'd prefer unwasm to error out if there's an unresolvable ESM import, but I think that will break the current behavior where resolving is optional.