Add WebRTC IO support

[mirsella]

Hello !

Closes #98

Adds aeronet_webrtc, with native client/server support and browser client support. WebRTC signaling is kept separate from the IO layer and routed through an application-provided signaling service.

Each session uses one unordered, unreliable binary DataChannel with a 1000-byte MTU. Reliability, ordering, and fragmentation remain in aeronet_transport.

Added lines by category:

• transport implementation: 3,180
• unit and integration tests: 1,840
• browser/native test harness: 847
• Cargo.lock: 1,032
• manifests and CI configuration: 147
• documentation and changelog: 108

Tested with native and WASM checks, headless Chromium, direct connections, and TURN over UDP, TCP, and TLS.

Publishing requires releasing aeronet_tokio_runtime first.

No problem if this is not an implementation or direction you want for Aeronet. Feel free to close the PR.

[aecsocket]

webrtc crate README prose seems entirely AI generated, and it's impossible to understand (opus 5?). code is similarly verbose. I have no clue what the structure of the crate is, how to use it, the decisions behind its architecture, or anything. It's just a description of the code which I could just as easily get by asking AI "what does this crate do". The point of a README is to have the human in the loop explain why they made the decisions they did, how you're supposed to use the crate (the happy path), etc. README should also serve as an introduction to, why would I use this? what is STUN/TURN/ICE/etc.? what are the pros and cons of using this IO compared to webtransport?

I also have no clue what browser_harness is supposed to be. In general, the code is hard to follow, and has a lot of cfgs which I'm confident can be simplified with better module structuring, cfg_if, and some more effort put into organisation.

While I'm happy to include a WebRTC IO layer I'm not confident in reviewing or merging this PR because I can't follow the logic here; especially since it seems almost 100% AI generated, I don't see what decisions and trade-offs you as a human specifically have made in this code. I could just as easily prompt Codex "write a webrtc IO layer" and get the same result - I'm not interested in merging that upstream without a human's eyes here. (Especially because the aeronet codebase and API surface is so tiny!)

This should stay as an out-of-tree crate, but I'm happy to re-review after real world usage and polish. I'm gonna reserve aeronet_webrtc for this in the future.

[mirsella]

thank you for your quality answer, and sorry for wasting your time. you're right this is too sloppy, got ahead of myself