[eXpl0it3r]

Description

The WinUI adapter got added, but wasn't packaged yet, and a closer look showed a few things that didn't work at all. This fixes the adapter, brings the demo on par with the WPF one and adds the package to CI.

Fixes in the adapter:

• The controls couldn't take focus, a UserControl isn't a tab stop and the root ScrollViewer took the focus on every unhandled click, so copy (Ctrl+C), select all and the keyboard scrolling never got a key event. HtmlPanel marks the press as handled now, HtmlLabel still lets it bubble to its parents, as in WPF
• Fonts that aren't installed, from @font-face or HtmlRender.AddFontFamily, fell back to the default font, DirectWrite only finds them with the font file in front of the family name
• ImageLoad and StylesheetLoad from a background thread were queued without waiting, so changes of the handler to the event args came too late, they're raised synchronously on the UI thread now, like WPF's Dispatcher.Invoke
• The hand-made double-click detection didn't pass the second press on to the core, DoubleTapped is used now and every press goes through HandleMouseDown as in WPF
• Loading an image could deadlock on the UI thread, saving an image blocked on the async file picker and its errors went nowhere, they're reported through RenderError now
• Drag & drop of the selection was a no-op, it's implemented with StartDragAsync now
• Text is measured including trailing whitespace with LayoutBoundsIncludingTrailingWhitespace, as WPF does, instead of a sentinel glyph trick
• HtmlRender.AddFontFamily takes the URI of a font file and registers its families, so you don't need to know the family name in the file
• The generated comments are gone or cut down to the why

The demo now has the same features as the WPF demo:

• Toolbar with sample window, browser comparison (WebView2), open external, generated HTML, image and PDF generation and the performance run
• Input HTML editor with syntax coloring and the fixed HTML view
• HTML tooltip, the demo links and the custom font

WinUI has no property grid, so the sample window gets a small settings panel instead, and the performance run can't paint between the samples, as there's no way to pump the messages.

For the package, HtmlRenderer.WinUI now only depends on Win2D 1.4.0 instead of the full Windows App SDK 2.6.5 metapackage. Win2D brings in WinUI from Windows App SDK 1.8, so apps on 1.8 or newer can use it, while the metapackage forced 2.6.5 onto every app. Note that CI and the demo build against Windows App SDK 2.6.5, so 1.8 is the minimum Win2D sets, not something CI tests. CI packs it on Windows, which also puts it into the NuGet push on tags. The READMEs mention WinUI now and the quick start uses WinUI's using: XAML namespace instead of WPF's clr-namespace:.

How to test this PR?

CI should succeed, the Windows jobs should upload HtmlRenderer.WinUI in the NuGet artifacts. Additionally, run the WinUI demo:

• Select text with the mouse and with a double-click, copy it with Ctrl+C and the context menu
• Scroll with the keyboard and the mouse wheel
• Drag a selection into another app, I couldn't test the drop with simulated input
• Try the toolbar buttons, the links in the intro sample and the sample window