Upgrade wasmtime to v41 (#897)

The wasmtime version is really far behind, so updating to a newer
version.

v41 - https://github.com/bytecodealliance/wasmtime/releases/tag/v41.0.0
v40 - https://github.com/bytecodealliance/wasmtime/releases/tag/v40.0.0
v39 - https://github.com/bytecodealliance/wasmtime/releases/tag/v39.0.0
v38 - No release

The v42 introduces a new error type that will require changing a bunch
of code, so I only upgraded to v41.

Upgrade wasmtime to v41 (#897)

The wasmtime version is really far behind, so updating to a newer
version.

v41 - https://github.com/bytecodealliance/wasmtime/releases/tag/v41.0.0
v40 - https://github.com/bytecodealliance/wasmtime/releases/tag/v40.0.0
v39 - https://github.com/bytecodealliance/wasmtime/releases/tag/v39.0.0
v38 - No release

The v42 introduces a new error type that will require changing a bunch
of code, so I only upgraded to v41.

Fix pool thread safety issues (option 2) (#893)

This is an alternative to #892 

The pool implementation had an unsound `unsafe impl Sync` on `PoolInner`
containing `Vec<PoolPlugin>` where `PoolPlugin` was
`Rc<RefCell<Plugin>>`. This caused intermittent "RefCell already
borrowed" panics in multi-threaded usage (issue #891).

The problem with the original design was that it assumed external
locking (the pool's `Mutex`) would be sufficient to make `Rc<RefCell<>>`
safe to share across threads. However, there were several issues that
made the design unsound:

1. `PoolPlugin` had no `Drop` implementation to synchronize refcount
decrements. When dropped on different threads, unsynchronized `Rc`
refcount modifications could lead to data races.
2. The pool used `Rc::strong_count == 1` to track availability, but had
no control over when clones were created or destroyed. Callers could
clone and keep `PoolPlugin` instances, breaking the availability
tracking.
3. The `PoolPlugin` type didn't leverage the type system to enforce safe
usage patterns; it relied entirely on external locking that the type
system couldn't verify.

This replaces the unsafe implementation with proper thread-safe
primitives and move semantics inspired by the deadpool crate.

Changes:

- Replace shared `Rc<RefCell<Plugin>>` with move semantics: plugins are
moved out of a `VecDeque` when checked out and moved back on drop
- `PoolPlugin` now owns the plugin and implements `Drop` to
automatically return it, making checkout/return atomic and type-safe
- Add `unsafe impl Send/Sync` for `UserDataHandle` to complete the chain
of unsafe assertions. This trusts that the existing `unsafe impl<T> Send
for UserData<T>` is sound (verified: `UserData::get()` only returns
`Arc<Mutex<T>>`, never extracts `T`, so it cannot be moved across
threads unsafely)
- Replace busy-wait polling with `Condvar` for efficient waiting
- `PoolPlugin` implements `Deref`/`DerefMut` for ergonomic access
- Use `Weak` reference to pool so checked-out plugins don't keep pool
alive
- Fix `function_exists` to handle timeout gracefully instead of
panicking
- Add test for pools with captured `PluginBuilder` containing custom
functions

Breaking API changes:

- `PoolPlugin` no longer has a `.plugin()` method - it now implements
  `Deref`/`DerefMut`, so you can use it directly where you previously
  called `.plugin()`. Example: `pool.get()?.call(...)` instead of
  `pool.get()?.plugin().call(...)`
- `PoolPlugin::call()` now takes `&mut self` instead of `&self` (direct
  ownership instead of interior mutability via `RefCell`)

Fixes #891

feat: expose building a CompiledPlugin with a fuel limit (#883)

Expose a new method `extism_compiled_plugin_new_with_fuel_limit` to
build a CompiledPlugin with a fuel limit.

Fixes #882

fix: use gh release download instead of downloading from github actio…

…n artifacts in dotnet workflow (#857)

It seems like at some point we changed the `release.yml` workflow to
create multiple artifacts instead of one `release-artifacts` tarball. I
changed the .NET Nuget workflow to be more like Python

fix: remove unwrap() from extism_compiled_plugin_new

`extism_compiled_plugin_new` would panic on bad manifest input (there's
a test in the python sdk [1] that hits this directly.) Catch the error and
set `errmsg` appropriately instead.

Additionally: golf the function pointer casting for the various `plugin_new` calls,
with the goal of reducing the number of allocations by leaning on iterator size
hints (and reducing the scope of `unsafe{}` use.) This part can be severed: it
introduces a breaking change. Previously `NULL` values were silently accepted in
the `functions**` list; now they fail. This maintains consistency with behavior on
"consumed" `ExtismFunction` pointer.

[1]: https://github.com/extism/python-sdk/blob/main/tests/test_extism.py#L50-L53