Build for wasm32-unknown-unknown

[vlad-salone]

rav1d doesn't build for wasm32-unknown-unknown today. With assembly off, every one of the 34 errors is a libc name: the target has no C library, so the libc crate defines neither ptrdiff_t, intptr_t, uintptr_t and off_t nor the errno constants there.

# main at d3d1cd6: 34 errors. this branch: builds
cargo build --target wasm32-unknown-unknown --no-default-features --features bitdepth_8,bitdepth_16

This PR keeps the C names and changes where they come from:

• src/c_types.rs defines ptrdiff_t, intptr_t and uintptr_t as isize, isize and usize, which is how libc defines them on every target it supports. The 13 files that imported them from libc import them from there.
• The off_t and the errno values still come from libc wherever there is a C library. On all(target_family = "wasm", target_os = "unknown"), off_t is i64 and the errno values are Linux's. Nothing on that target can call the C API, so Rav1dError only needs them distinct.

No other target changes: the types are identical, and the errno values still come from libc.

With the Rust API from #1439, this is enough to decode in the browser. I checked the nine AVIF fixtures of sqzer (8 and 10 bit, 4:2:0, 4:4:4, monochrome, and an alpha item) through Decoder::send_data and get_picture in Node 24: the planes hash the same as from the native build of the same commit. cargo fmt --check, cargo clippy -- -D warnings and the unit tests pass on stable, and clippy passes for the wasm32 target too.

Not included: a CI job. A cargo check for wasm32-unknown-unknown with assembly off would keep this from regressing and take about ten seconds. Do you want it in this PR, in a follow-up, or not at all?

Side Note: This PR was written with usage of AI, but the change is fairly simple. Either way take causion merging it