Lock Rust version to 1.92 to workaround WASI p2 bug

[jeffcharles]

Description of the change

Locks the Rust version to 1.92.0 instead of using stable which is currently 1.93.0.

Why am I making this change?

Fixes #1115

The 262 tests are broken for Rust 1.93.0 with WASI preview 2 due to a bug in Rust's standard library for WASI preview 2. The bug is fixed when run with a nightly for Rust 1.95.0 so presumably we can switch back to using stable when 1.94 or 1.95 is released on the stable channel.

Checklist

• I've updated the default plugin import namespace and incremented the major version of javy-plugin-api if the QuickJS bytecode has changed.
• I've updated the relevant CHANGELOG files if necessary. Changes to javy-cli, javy-plugin, and javy-plugin-processing 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.

[saulecabrera]

We've been in this situation a couple of times [1] [2], I wonder if we should define a supported Rust version policy, which would hopefully avoid intermittent/unexpected failures like this one. I'm fully aware that this is happening with stable, but with a clearly defined policy, the Rust version upgrade process (e.g., v1 -> v2) is explicit rather than implicit. Thoughts?

[jeffcharles]

I have two reasons I prefer defaulting to stable with an automatic update of Rust versions:

1. Updating our dependencies will sometimes force us to use a newer Rust version. In some cases we need to adopt those dependency updates due to CVEs.
2. We find out about behaviour that breaks in the latest stable Rust version or with Clippy much sooner so that gives us more time to update our code if we need to.

The case I don't want to run into in the future if we lock our Rust version is: say we have a dependency that has a CVE filed against it so we have to update it, but the updated dependency requires a newer Rust version than we're using. So we try to update our Rust version, but then we get CI failures from updating Rust, so then we have to do other code changes that might take a while (for example, what happened with WASI p2 removing the WASI p1 imports for stdio operations), before we can ship a change to fix the CVE. But if we kept up with the latest stable Rust, we find the problem, we can file an issue to fix CI, we can lock to the last working stable version, then perform the CVE update, then do whatever work we need to do to fix CI with the latest stable Rust, then switch to latest stable. It's more PRs but we find problems sooner so we have the option of fixing the problems sooner.