Add io_uring integration for Linux performance optimization

[kajukitli]

Adds io_uring support for Linux performance optimization.

Performance

WebSocket benchmark results:

• tokio: ~4ms for 100 echo messages
• io_uring: ~3ms for 100 echo messages
• 20% performance improvement

Implementation

• io-uring feature flag with conditional compilation
• Drop-in replacement for tokio::net types
• Task-based AsyncRead/AsyncWrite adapter for io_uring compatibility
• Full WebSocket protocol support through existing APIs

Usage

// Enable with feature flag
use fastwebsockets::uring::{TcpStream, TcpListener, start};

start(async {
    let listener = TcpListener::bind(addr)?;
    let (stream, _) = listener.accept().await?;
    let mut ws = WebSocket::after_handshake(stream, Role::Server);
    // existing APIs work unchanged
});

Testing

cargo test --features io-uring
cargo run --example websocket_bench --release --features io-uring
cargo run --example simple_bench --release --features io-uring

Requirements

Linux 5.11+, x86_64/aarch64. Optional dependency on tokio-uring = "0.5.0".

Without the feature flag, uses standard tokio with zero overhead.

[divybot]

Maintenance scan note: this currently fails the repo CI shape because .github/workflows/rust.yml runs cargo build --all-features --all-targets on macOS and Windows too. Since this PR adds a Linux-only io-uring feature, the feature needs to be target-gated so non-Linux all-features builds still compile, or the CI matrix needs a clear Linux-only feature job plus default builds on the other platforms.

A couple of concrete cleanup items before this is reviewable:

• gate tokio-uring usage and any examples/benches that require it with target_os = "linux", not just feature = "io-uring";
• avoid committing generated/local files like pr_description.md;
• trim the many benchmark/demo files down to the smallest evidence needed, or split benchmarking from the library API change.

Also note that #133 is the currently active ServerEngine/Reactor performance path, so this PR should either rebase around that direction or explain why a separate tokio-uring API is still the intended shape.