Baixar Wasmtime 13.0.0 per a Windows

Added
- Configuration of mach ports vs signals on macOS is now done through a Config instead of at compile time. #6807
- Engine::detect_precompiled{,_file} can be used to to determine whether some bytes or a file look like a precompiled module or a component. #6832 #6937
- A new feature "wmemcheck" has been added to enable Valgrind-like detection of use-after-free within a WebAssembly guest module. #6820 #6856
- The wasmtime CLI now supports executing components. #6836
- Support for WASI preview2's TCP sockets interface has been added. #6837
- Wasmtime's implementation of the wasi-nn proposal now supports named models. #6854
- The C API now supports configuring native_unwind_info, dynamic_memory_reserved_for_growth, target, and Cranelift settings. #6896 #6934
- The wasmtime crate now has initial support for component model bindings generation for the WIT resource type. #6886
- Cranelift's RISC-V backend now has a complete implementation of the WebAssembly SIMD proposal. Many thanks to Afonso Bordado for all their contributions! #6920 #6924
- The bindgen! macro in the wasmtime crate now supports conditional configuration for which imports should be async and which should be synchronous. #6942

Changed
- The pooling allocator was significantly refactored and the PoolingAllocationConfig has some minor breaking API changes that reflect those changes.
Previously, the pooling allocator had count slots, and each slot had N memories and M tables. Every allocated instance would reserve those N memories and M tables regardless whether it actually needed them all or not. This could lead to some waste and over-allocation when a module used less memories and tables than the pooling allocator's configured maximums.
After the refactors in this release, the pooling allocator doesn't have one-size-fits-all slots anymore. Instead, memories and tables are in separate pools that can be allocated from independently, and we allocate exactly as many memories and tables as are necessary for the instance being allocated.
To preserve your old configuration with the new methods you can do the following:

let mut config = PoolingAllocationConfig::default();

// If you used to have this old, no-longer-compiling configuration:
config.count(count);
config.instance_memories(n);
config.instance_tables(m);

// You can use these equivalent settings for the new config methods:
config.total_core_instances(count);
config.total_stacks(count); // If using the `async` feature.
config.total_memories(count * n);
config.max_memories_per_module(n);
config.total_tables(count * m);
config.max_tables_per_module(m);

There are additionally a variety of methods to limit the maximum amount of resources a single core Wasm or component instance can take from the pool:
- PoolingAllocationConfig::max_memories_per_module
- PoolingAllocationConfig::max_tables_per_module
- PoolingAllocationConfig::max_memories_per_component
- PoolingAllocationConfig::max_tables_per_component
- PoolingAllocationConfig::max_core_instances_per_component
These methods do not affect the size of the pre-allocated pool. #6835
- Builder methods for WASI contexts now use &mut self instead of self. #6770
- Native unwinding information is now properly disabled when it is configured to be turned off. #6547
- Wasmtime's minimum supported Rust version (MSRV) is now 1.70.0. Wasmtime's MSRV policy of supporting the last three releases of Rust (N-2) is now additionally documented. More discussion can additionally be found on the PR itself. #6900
- Wasmtime's support for DWARF debugging information has seen some fixes for previously reported crashes. #6931

Removed
- Wasmtime's experimental implementation of wasi-crypto has been removed. More discussion of this change can be found on #6732 and #6816
- Support for union types in the component model has been removed. #6913