Signalling goes through pluggable transport; SignalError variants revamped

Breaking Changes

Route LiveKit signalling through a pluggable transport (new livekit-net crate).

The signalling WebSocket and the two pre-connect HTTP GETs (validate, region discovery) now go through pluggable transport traits (WsClient for the WebSocket, HttpClient for request/response) resolved from a process-global registry with independent slots — a consumer can bring only HTTP, or only WebSocket. The new livekit-net crate owns the WebSocket/HTTP/TLS stack behind those traits and ships native (tokio / async-std) backends. Native builds are unchanged in behavior.

Breaking (livekit-api, and livekit via EngineError::Signal):

• SignalError::WsError is removed — tungstenite is no longer part of the public API. A failed WebSocket handshake now surfaces its HTTP status as SignalError::Client/Server; transport connection and close failures surface as the new SignalError::Connection(String) / SignalError::Closed variants (previously all collapsed into Timeout).
• SignalError is now #[non_exhaustive], and gains a SignalError::TransportNotConfigured variant — returned when no transport is registered (host/foreign builds must call livekit_net::set_ws_client / set_http_client before connecting). This is a permanent configuration error; callers must not retry.
• The signalling WebSocket/HTTP/TLS crates are no longer transitive dependencies of livekit-api; TLS features delegate to livekit-net. Existing signal-client-tokio / -async / -dispatcher and TLS feature names are unchanged.

Fixes

• Data tracks schema metadata support.