gRPC-xDS: xDS Federation (A47)

_I don't have the rights to create a sub issue of https://github.com/grpc/grpc-rust/issues/2753_
## Feature Request

### Crates
The implementation is scoped to xds-client/tonic-xds crate

### Motivation
xds-client at the moment does not support multiple authority

### Proposal
Add support for https://github.com/grpc/proposal/blob/master/A47-xds-federation.md

#### Rough plan
[ ] Add canonical xdstp resource-name parsing
[ ] Add authority configuration types
[ ] Refactor the single ADS worker into actor plus server tasks
[ ] Add authority-aware resource routing and caching

### Alternatives

### Open questions (more will come as I make progress)
I'm missing some information on current crates interactions and evolution.
* `grpc-xds` would eventually need use the boostrap config struct
* Deadlock issue https://github.com/grpc/grpc-rust/issues/2778#issuecomment-5184644089 might require some changes

## Proposed update

### Blocking behavior

- [ ] The client worker historically owned one ADS stream, so all subscriptions were sent to the top-level server. Per-authority routing requires independent stream state, reconnect, nonce/version, backoff, and ACK/NACK ordering.
- [ ] Server identity cannot be the URI alone. Stream deduplication must include URI, credentials, and server features.
- [ ] Resource/cache state keyed only by a bare name can collide across authorities. The full canonical resource name must be retained through LDS, RDS, CDS, and EDS.
- [ ] Bootstrap authorities and listener templates cannot be enabled until watches are routed to the corresponding authority server; partial support could send resources to the wrong control plane.

### Missing features

- [ ] xTP1 `xdstp://` resource-name parsing and canonicalization.
- [ ] Authority extraction with exactly-once percent decoding.
- [ ] Context-parameter canonicalization.
- [ ] Validation that the embedded xTP1 resource type matches the watched type.
- [ ] gRFC A47 bootstrap `authorities` and client listener resource-name templates.
- [ ] Per-authority xDS server selection and stream sharing for identical server configurations.
- [ ] gRFC A71 priority fallback and recovery per authority.
- [ ] Per-server channel credentials and server-feature handling.
- [ ] Authority-safe cascading subscriptions and cache keys through LDS/RDS/CDS/EDS.

### Issues found

- [ ] Connection construction, stream creation, and stream write failures did not always reach the worker, preventing fallback and disconnected metrics.
- [ ] Wildcard subscriptions could be replaced by named subscriptions on later requests or ACKs.
- [ ] An invalid replacement could be marked `NACKedButCached` and then incorrectly overwritten as deleted.
- [ ] ACK/NACK tasks could complete out of order on the same ADS stream.
- [ ] Per-resource validation errors did not retain `ProcessingDone`, allowing a NACK before watcher processing completed.
- [ ] A dirty subscription marker could be lost when the command channel remained full.
- [ ] Stale dirty and ACK state could remain after a stream was removed.
- [ ] URI authorities could be decoded twice, causing distinct encoded authorities to collide.
- [ ] Decoded authorities were not always percent-encoded when rebuilding target URIs or listener templates.
- [ ] Malformed `xdstp:` names could fall back to legacy-name handling.
- [ ] `xdstp` names with the wrong embedded resource type could be subscribed to or accepted.
- [ ] Mutable or debug-derived server-extension identity could invalidate hash keys or expose credential data.

Start by reading the xds-client/tonic-xds crate and gRFC A47, then trace the current ADS worker, bootstrap handling, and resource subscription and cache flow; the issue names no specific files or tests. Done means the listed federation, authority routing, stream-management, validation, fallback, and state-handling requirements are implemented and validated.

Written by the indexing model from the issue text.