Feature Request: Decouple getRuntime to Allow Dynamic Runtime Switching and Improve Performance

First of all, thank you for the fantastic Rive product! It's incredibly powerful and enables amazing animations.

I've encountered a limitation when trying to dynamically switch between rendering runtimes (WebGL2, WebGL, Canvas) within the same application. Currently, the wrapper implementations, while very consistent, don't allow for switching the runtime on-the-fly for a specific animation without re-initializing and re-downloading the entire WASM wrapper code. This hurts performance and limits flexibility.

I propose decoupling the getRuntime method or the runtime selection logic into a separate module. The ideal solution would allow passing a runtime type (e.g., webgl2, webgl, canvas) as a parameter during the wrapper's initialization.

This would enable:

• Dynamic runtime selection per animation instance based on its complexity or the current device capabilities.
• Avoiding the performance cost of re-downloading and re-initializing the JavaScript wrapper code when a different runtime is needed.
• Greater flexibility for building complex applications that integrate multiple types of animations.

The current alternative is to create multiple instances of the entire Rive WASM module for each required runtime, which is inefficient for bundle size and application load time.

Additional context:
This change would significantly improve the developer experience by making it easier to build adaptive and high-performance web applications that leverage Rive animations to their full potential.

Thank you for considering this feature!

Start by locating getRuntime and the wrapper initialization path mentioned in the issue, then trace how runtime selection handles WebGL2, WebGL, and Canvas. Compare the current per-runtime module initialization and identify what would be needed to pass a runtime type without re-downloading or re-initializing the wrapper. Done means runtime choice can vary per animation instance while preserving existing initialization behavior.