Adapt streaming quality to available bandwidth

Video encoding quality is fixed at connection time (--quality, default 75) for the whole session, regardless of what the client's actual link can sustain. This adds an adaptive mode where the configured quality acts as an upper bound and H.264 encoding quality gets nudged toward what the client's measured bandwidth and RTT can support, rechecked every 1.5s. It's off by default (AdaptiveQuality=false).

Can be enabled with KCM checkbox or --adaptive-quality, or force it off for a single run with --static even when it's enabled in the config.

The bitrate target comes from a small resolution-indexed table. Pulled this concept from RustDesk, and this table is derived from its numbers. Open to discussion on if this is something that is helpful or any suggested different approaches. Couldn't find a consensus in my research on how to do this.

Quality moves in fixed steps (-10 down and +5 up) and RTT well above the session's established baseline counts as congestion and triggers an immediate backoff. Bandwidth readings get the same exponential smoothing already used for RTT, since when I went to test this a raw single 500ms measurement was noisy enough to cause visible flapping.

Progressive/RemoteFX sessions aren't affected. FreeRDP's progressive_compress() has no quality or bitrate parameter to adapt, so this only applies to H.264 sessions.

Opt-in, not a new default.

Manually verified against a tc/netem shaped connection.