[Feature Request]Expose Typed Capability-Set Hooks for RDP Connector and Proxy Clients

## Context

Applications that proxy or relay RDP often maintain two independent RDP
connections: one to the viewer and one to the target server.

To make the two sessions interoperable, the target-side connector needs to:

1. advertise the viewer's actual capability sets in its Client Confirm Active;
2. expose the target server's Demand Active capability sets so they can be
presented to the viewer during activation or reactivation.

This is useful for RDP gateways, protocol relays, recording proxies, and other
applications that do not render the target session themselves.

## Current Limitation

`ironrdp-connector` currently consumes the target's Demand Active capability
sets internally and uses them to construct a synthesized Client Confirm Active.
The parsed server capability sets are not returned in `ConnectionResult`, and
the generated Client Confirm Active cannot be customized by callers.

The relevant logic is currently internal to
`ironrdp-connector/src/connection_activation.rs`.

A downstream RDP relay can work around this by wrapping the transport and
rewriting the encoded Confirm Active PDU, while scanning received bytes for the
Demand Active PDU. This avoids forking IronRDP, but couples the application to
transport framing and wire-level behavior.

## Proposed API

I would appreciate guidance on the preferred API shape, but the needed
capabilities appear to be:

### 1. Expose the Server's Negotiated Capability Sets

Return the parsed Demand Active capability sets through `ConnectionResult`, or
through a typed accessor or callback associated with
`ConnectionActivationSequence`.

The result should be owned because proxy applications may need the capability
sets after `connect_finalize` has completed.

### 2. Allow Customization of Client Confirm Active

Provide a typed way for callers to customize the capability sets sent in Client
Confirm Active.

Possible designs include:

- an explicit capability-set override;
- a callback or policy receiving the server capability sets and IronRDP's
generated defaults;
- a public activation-sequence configuration method.

The API should preserve IronRDP's existing defaults and negotiated values, such
as `MultiFragmentUpdate`, unless the caller intentionally replaces them.

### 3. Cover Reactivation

The same customization and observation mechanism should remain usable for
deactivation-reactivation sequences created through
`ConnectionActivationFactory`.

## Non-Goals

This proposal is not asking IronRDP to implement a relay or proxy.

It also does not require exposing connector state-machine internals or adding a
raw transport interception hook. The desired interface is at the parsed,
typed capability-set level.

## Compatibility and Tests

Existing clients should retain their current behavior when no customization is
requested.

Tests should cover:

- returning the target's Demand Active capability sets;
- customizing the generated Client Confirm Active;
- preserving existing defaults when no override is supplied;
- activation and reactivation behavior;
- unchanged behavior for ordinary connector users.

If adding fields to `ConnectionResult` would be source-breaking for downstream
struct literals, an accessor or a new result type may be preferable.

I have done a prototype implementation to achieve native RDP relay for warpgate(https://github.com/warp-tech/warpgate). I would be
happy to contribute an IronRDP PR once the maintainers agree on the API shape.

Start by reading ironrdp-connector/src/connection_activation.rs and the ConnectionResult, ConnectionActivationSequence, and ConnectionActivationFactory entry points, then inspect the existing connector tests. Trace how Demand Active capability sets flow into synthesized Client Confirm Active and connect_finalize. Done means typed observation and customization work for activation and reactivation while preserving defaults and ordinary connector behavior.

Written by the indexing model from the issue text.