Implement Testing for Custom Logging

This was referenced here: https://github.com/fermyon/spin/pull/482, and should be done after the PR is merged.

Here's a compilation of relevant comments:

@itowlson

It would be super useful to have an integration test for this - I know it's fiddly because CLP can only be injected through hosting, but it would really help with confidence when changing things in the I/O subsystem.

@me

The way I've tested this feature locally was:

• get an app w/ spin_loader::from_file,
• create ExecutionContextConfiguration object w/ CustomLogPipes,
• get a builder w/ spin_engine::Builder::with_engine,
• HttpTrigger::configure_execution_context,
• builder.build()
• get component_triggers from app,
• HttpTrigger::new w/ all that,
• .run() the http_trigger, and then
• curl it to see the result of the .wasm module's println!s.
  Are you suggesting recreating something like that in the integration tests? If not, how would you go about it?

@itowlson

Something like that would be great. Unfortunately the integration tests only have infrastructure for the normal Spin binary at the moment (via SpinTestController), so there's new infra to be built here. If you don't want to tackle that, raise an issue and I'll get onto it once this is merged. (And if you could share your existing manual test code in the issue, that would be a big timesaver!)

@me

Hmmm~ I just don't know how much time I can afford to allocate there. SOOO... If that's ok then, I think I'll pass that onto you and help w/ reviewing.

Here's where we are using the CustomLogPipies like I mentioned: https://github.com/Mossaka/containerd-wasm-shims/blob/main/containerd-shim-spin-v1/src/main.rs

@itowlson

Fair enough - thanks for the pointer!

Start by reviewing the custom logging work referenced in PR 482 and the existing integration-test infrastructure around SpinTestController. Follow the described flow through spin_loader::from_file, CustomLogPipes, ExecutionContextConfiguration, spin_engine::Builder::with_engine, and HttpTrigger. Done means an integration test exercises a WASM module's println! output through custom log pipes rather than relying on manual curl testing.