feat(wasm): add WASI compatible runtime

[niallnsec]

Summary

First, thanks again for the time spent reviewing and merging the initial browser-oriented WASM support. That change opened the door for using yara-x in browser-hosted WebAssembly environments.

This PR is intended as the smallest possible follow-up to close the remaining gap on the WASM side: support for wasm32-wasip1 in non-browser hosts.

The goal here is not to introduce language bindings or a new integration surface upstream. It is to make the existing WASM support more complete by adding a narrowly scoped host-bridge runtime for WASI hosts, while keeping the existing native and browser paths intact.

What this PR adds

• a wasm32-wasip1 runtime backend
• a small WIT-defined host bridge for validating, instantiating, and executing generated rule modules
• session-aware runtime state so host-managed globals, memories, instances, and callbacks remain isolated
• WASI-compatible timeout handling
• a small include-resolution adjustment for environments where canonicalize() is unsupported

Why this is useful

The browser runtime solved one half of the WASM use case: environments with JS/WebAssembly host APIs.

This PR addresses the other half: environments that can host WASM through WASI but do not provide browser APIs.

That is useful for:

• sandboxed server-side scanning services
• edge/serverless WASM runtimes
• plugin-style integrations where shipping a native shared library is undesirable
• out-of-tree bindings that want a single WASM guest artifact instead of a native dependency
• embedders that want stronger isolation than a direct native library integration

My immediate downstream use case is a separate set of CGO-free Go bindings, but I think the upstream value is broader than that: this makes yara-x easier to consume from any non-browser WASM host without requiring upstream to own those bindings.

Scope and impact

I expect the main concern here to be maintenance cost, so I tried to keep the change as additive and low-impact as possible.

• The new backend is fully cfg-gated and only selected for wasm32-wasip1.
• Native builds are unchanged.
• Existing non-WASI browser builds are unchanged.
• The public API impact is minimal.
• The bridge ABI is documented explicitly in WIT and in the accompanying host-bridge notes.
• This does not add any in-tree Go code or other language-specific binding code.

In other words, this is meant to extend the runtime matrix, not to change the core architecture or redirect the project toward maintaining downstream bindings.

Why upstream support matters

This runtime is much more useful as an upstream capability than as a fork-only patch.

If WASI support lives upstream, downstream projects can build on a documented and maintained target instead of each carrying their own runtime patch set. That lowers duplication and makes it easier for other community members to experiment with non-browser WASM integrations without having to maintain their own branch.

Validation

I verified the new path with:

• native workspace checks
• yara-x library checks for wasm32-wasip1
• an out-of-tree WASI host consumer using the new runtime bridge

That downstream consumer is my immediate use case, but the runtime itself is designed to be generic and reusable.