[HotReload] Surface XAML Incremental Hot Reload diagnostics for IDE tooling

[noiseonwires]

Description

Incremental contribution to feature/xaml-incremental-hotreload.

Extends HotReloadDiagnostics so IDE tooling (the Visual Studio / VS Code MAUI
Hot Reload diagnostics, a.k.a. "XamlTools") can classify a hot reload cycle as
XAML Incremental Hot Reload (XIHR), report its apply stats, and surface
per-instance failures. Today the tooling only sees a generic managed-code delta, so
it misclassifies XAML SourceGen edits as plain C# and can't report the incremental
apply result.

All changes are purely additive to the diagnostics surface — no change to the
hot reload apply itself, and no breaking API changes.

New / changed public API (Microsoft.Maui.Controls.Xaml.Diagnostics)

• HotReloadDiagnostics.UpdateSkipped — new event. Terminal signal raised when an
  update is recognized (has generated UpdateComponent() types) but nothing is
  dispatched because there are no live instances to patch, so observers always get a
  definite outcome even when UpdateApplied never fires.
• HotReloadRequestedEventArgs.HandledTypes — the recognized incremental-XAML
  subset of UpdatedTypes. Raised synchronously, before any UI-thread dispatch, so
  tooling can classify the update type inline (XIHR vs. non-XAML) without awaiting the
  async apply.
• HotReloadErrorEventArgs.Version — the update-cycle version a per-instance
  failure belongs to (matches the corresponding HotReloadAppliedEventArgs.ToVersion),
  so failures can be correlated with their apply.
• HotReloadSkippedEventArgs — new event args for UpdateSkipped (UpdatedTypes,
  HandledTypes, Timestamp).

Handler (XamlIncrementalHotReloadHandler)

• Builds the handledTypes set and raises OnUpdateRequested synchronously before
  dispatch.
• Raises OnUpdateSkipped for a recognized-but-empty batch (returns without dispatch).
• Passes toVersion to OnUpdateFailed.
• Allocates the diagnostic version only for non-empty batches, keeping the version
  stream gap-free (every increment is paired with an UpdateApplied).

Firing contract (documented in-code)

The three files carry brief "XamlTools contract" comments describing the reflection-by-
name binding surface tooling relies on: the type/event/property names, the
EventHandler<T> shapes, and the ordering guarantees — UpdateRequested is synchronous
and pre-dispatch; a dispatched batch ends with exactly one terminal UpdateApplied
(always raised, even if every instance failed) or UpdateSkipped; each UpdateFailed
precedes its batch's UpdateApplied.

Issues Fixed

Fixes #

Testing

• Added XamlIncrementalHotReloadHandlerTests (7 tests, Controls/tests/Core.UnitTests)
  covering: UpdateRequested/HandledTypes classification, UpdateApplied
  instance/version/duration, UpdateFailed per-instance + Version correlation, and the
  UpdateSkipped no-live-instances path. Uses a MainThread custom-implementation
  harness for the UI-thread dispatch.
• Verified end-to-end on a physical Android device with the consuming IDE tooling:
  a XAML SourceGen edit is classified as xaml-sourcegen and the IDE reports the
  incremental apply (instance count, version 0→1, duration).

API Changes

Additive only — see the updated PublicAPI.Unshipped.txt for all TFMs.

[dotnet-policy-service]

Hey there @@noiseonwires! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[dotnet-policy-service]

Hey there @noiseonwires! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[noiseonwires]

@StephaneDelcroix that's the implementation of #36078 (comment) proposal