feat: add js-wasm bindings and formalise WASM runtime support

[niallnsec]

First split PR for JS binding support, as requested here: #594 (comment)

---

This PR adds a browser-facing JavaScript package for yara-x and the supporting library changes needed to run it on wasm32-unknown-unknown.

The main library change is a refactor of the internal WASM runtime layer so that non-Wasm targets continue to use wasmtime, while browser builds use a small compatibility shim over the host WebAssembly runtime. The browser-specific runtime code is isolated under lib/src/wasm/runtime/, which keeps the rest of the library largely unchanged and avoids spreading target-specific conditionals across the codebase.

On top of that, this PR adds a new in-tree js-wasm package. It exposes an object-based JavaScript API built around Compiler, Rules, and Scanner, and is packaged using a wasm-pack-based workflow with standard pkg/ output plus a no-modules bundle in dist/.

A fair amount of work also went into testing. The package now has:

• wasm-bindgen-test coverage for the Rust-facing WASM API
• browser-specific tests where appropriate
• end-to-end JavaScript tests against the built package outputs
• regression coverage using existing YARA-X module fixture data

While doing that work, I also fixed a browser-side issue in the time module and tightened a few API behaviours in js-wasm, including proper handling of accumulated compiler errors and propagation of compiler warnings in scan results.

The packaging flow was also tightened up to reduce output size:

• vt-module is not included in the browser package feature set
• the release build is size-focused and uses LTO
• wasm-opt is run as part of the package build
• the no-modules bundle now reuses the same .wasm binary as the standard package instead of shipping a duplicate copy

This leaves js-wasm as a browser-focused package with a cleaner runtime split, better test coverage, and a smaller final package size.

---

One item to query, I am not sure if removing the vt module was the right thing to do for the WASM browser build. The reason I removed it is that, as far as I can tell, the module is only used inside of VirusTotal's internal architecture and so is not something that normal users can take advantage of. Including the module adds an extra 1.5MB to the final build size, primarily due to the dependency on the pls crate.

Its not ideal as it means that I am currently loading the main lib into the js-wasm crate as a crate local import since you can't disable default features in an imported crate when using a shared workspace. I didn't want to remove it from the default features list at the lib level as that seemed like a significant change and I am already not clear on whether the vt module should be included in a browser focused build or not.