Add JS runtime option infra and redirect-stdout-to-stderr option

[jeffcharles]

Description of the change

The only functional change in this PR is adding support for -J redirect-stdout-to-stderr[=y|n] with a default of y to javy build. There are no other functional changes and behaviour without specifying that flag doesn't change since the existing code uses y for that setting implicitly.

At the code level, there's a few related changes in this PR:

1. Changing the static and dynamic codegen builders to use dedicated build functions instead of a single shared function so I can pass an argument to the static codegen build function and not to the dynamic build function. This involved deleting some code that is no longer referenced.
2. Adding a JsRuntimeOptionGroup struct, a JsRuntimeOption enum, and trait implementations to convert a Vec<JsRuntimeOption> to a JsRuntimeOptionGroup, and from a JsRuntimeOptionGroup to a javy_config::Config so we have a way of representing command line options for JS runtime settings.
3. For static module generation, use the JsRuntimeOptionGroup struct to generate the javy_config::Config instead of using Config::all() and pass it into the codegen struct.
4. For dynamic module generation, return an error if the JS runtime settings are different than the default settings.
5. Implement Default for the CodegenOptionGroup and use the defaults for converting from Vec<CodegenOption> to CodegenOptionGroup to keep it consistent with how JsRuntimeOptionGroup works.
6. Update the testing infrastructure to work with the new argument.
7. Update the testing infrastructure so we can inspect stderr from Javy when a compile or build command fails.

Why am I making this change?

See #702. I'm implementing this similarly to how I did for the codegen options. I'm also opting to return an error when generating a dynamic module if any of the JS runtime options are set to non-default values since those runtime options won't be applied to the generated module (the provider defines the runtime options). The refactoring of the codegen builder was because I wanted to try to make invalid state non-representable in the non-test code.

I can probably break this PR up if it's too large. I also tried avoiding any functional changes that I didn't have to so the PR could be kept smaller. Hence not bumping the provider version yet.

Checklist

• I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli and javy-core do not require updating CHANGELOG files.
• I've updated the relevant crate versions if necessary. Versioning policy for library crates
• I've updated documentation including crate documentation if necessary.

[jeffcharles]

The existing fuel consumption number on main is 37,309 for the log test is when compiled run on my Macbook.

[saulecabrera]

Looks great to me. Left one comment that I think makes sense to address before landing this one!

[saulecabrera]

On a second thought, I wonder if the builder is better suited to perform this validation?

That way:

1. We can keep the current build method, shared across dynamic/static codegen.
2. Perform the validation of the option groups through javy::Config
3. Keep main as slim as possible i.e., avoid baking in builder specific logic.

[saulecabrera]

In other words, we could modify the existing build method signature to be:

fn build<T>(config: javy_config::Config) -> Result<..>

[jeffcharles]

At some point in the future, if the defaults for build and compile diverge, the logic for validating the config for dynamic is going to depend on whether the build or compile command was used. But we can deal with that case when it actually comes up I guess.