Add ToyOS support

[Japabu]

ToyOS is an operating system written from scratch in Rust for x86-64. It has target_os = "toyos" support in a fork of rustc and std. Its display server is a userspace compositor daemon: clients create a window over IPC and draw into a shared-memory framebuffer.

What this adds

ToyOsWindowHandle and ToyOsDisplayHandle, in src/toyos.rs.

It follows the Haiku/Orbital pattern rather than inventing anything:

• ToyOsWindowHandle holds a NonNull<c_void> pointing at the client-side window object, like OrbitalWindowHandle::window.
• ToyOsDisplayHandle is empty — there is no global display connection to name, since each window carries its own connection to the compositor. Same situation as Haiku and Orbital, and it is kept Send + Sync for the same forward-compatibility reason.
• Registered at every site those two platforms are registered at: mod, the re-export, both enums, both from_impl! groups, and the assert_impl_all! checks in tests.
• Doc examples on each constructor, matching the surrounding modules.
• A CHANGELOG.md entry under Unreleased.

Nothing outside those files changes, and no existing platform is touched.

Testing

Against upstream master (1b85948):

• cargo fmt --all -- --check — clean
• cargo test across the feature powerset (default, --no-default-features, alloc, std, --all-features) with RUSTFLAGS="--deny=warnings" — all green; the three new doctests run and pass
• cargo doc --no-deps --document-private-items with RUSTDOCFLAGS="--deny=warnings" — clean
• cargo check --target wasm32-unknown-unknown --all-features — clean

I could not run typos or cargo hack locally; the powerset above was run by hand instead.

The handles are already in use by ToyOS's winit and softbuffer backends, so this is not a speculative variant.

Happy to adjust naming, the doc wording, or the thread-safety rationale to whatever you prefer — and if you would rather not carry handles for out-of-tree platforms at all, just say so and I will close this.