feat(go/nats): support concurrent message handling

[brooksmtownsend]

This PR changes the Go NATS client's handleMessage function in a small way, using a goroutine to handle the message instead of in the current execution context.

This came in response from a bug request on the wasmCloud community side that multiple concurrent invocations weren't being handled in parallel, so I think this should resolve that issue. I added (had copilot write) two tests to ensure that this functionality is correct for handling multiple requests, and I did validate that without this fix the test fails.

[rvolosatovs]

Thanks for the contribution!
I'm concerned about a few things in this implementation:

• unbounded goroutine count and corresponding memory/resource usage growth
• panic handling - I am not convinced that simply logging the panic is sufficient for every use case
• changed semantics regarding concurrency - currently there is no need for synchronization - this PR would change that and potentially break every user of this library
• maintenance cost/inconsistent behavior - TCP transport does not do this, for example, so servers would behave differently depending on the transport, which is against the principles of this project. I don't think we want to be reimplementing this logic for each transport
• (lower priority) perf cost - if an export does something very cheap, e.g. simply returns a constant - spawning a goroutine is redundant and likely would hurt the throughout, while also increasing memory usage

Personally, I don't think that wRPC should be blindly spawning goroutines - in my opinion it's the embeddeders job to do that in application-specific way.
That said, I'm not against introducing this functionality, but:

• it must be generic, i.e. not be transport-specific
• it must be configurable on per-export basis (just blanket on/off switch is fine for MVP, if path forward is clear)
• embedder must be handling the panic
• the goroutine count must be bounded in some way

Putting it all together I think the right place to put this feature would be the bindgen.

Therefore, here's what I think we should do:

• by default spawn a goroutine for each function marked as async in WIT (imports and exports, but just exports for now)
• reuse the async flag that already exists in the bindgen for configuring this functionality