XAML Language Server: Basic C++/WinRT project support (syntactic features)

Summary

The XAML language server currently only discovers .csproj files and relies entirely on Roslyn for type resolution, making it non-functional for C++/WinRT WinUI projects. Even Visual Studio's XAML IntelliSense has limited C++ support, so full parity isn't the goal — but we should provide syntactic features and a good UX for C++ developers.

Short-term wins (target: PR #50)

1. Detect .vcxproj alongside .csproj in project discovery

XamlProjectResolver.FindOwningProject() hardcodes *.csproj. Add *.vcxproj so C++ WinUI projects are at least recognized.

2. Graceful degradation when Roslyn can't load the project

When project discovery finds a .vcxproj, skip Roslyn loading and return a partial XamlResolution with classSymbol = null. Most features already handle null gracefully — verify they do and fix any that don't.

3. Syntactic features should work for C++ projects

These require no type system and should work automatically once project detection doesn't block:

• Formatting (document + range)
• Folding ranges
• Color swatches (hex values)
• Selection range expansion
• x:Name / x:Key hover, rename, references
• Document symbols
• Linked editing (tag pair sync)
• Syntax highlighting (TextMate grammar — already works)

4. Notification for reduced IntelliSense

When a C++/WinRT project is detected, show a one-time informational message explaining that type-aware features (completion, diagnostics, go-to-definition for types) are limited for C++ projects.

What won't work (expected)

• Element/property type completion (requires type system)
• Semantic diagnostics (unknown type, unknown property, etc.)
• x:Bind path resolution
• Event handler go-to-definition
• Code actions (quick fixes)

These are tracked in #222 for WinMD-based type resolution (two approach options documented there).

Research context

• No third-party VS Code extensions provide C++ WinUI XAML IntelliSense — we'd be the first
• Even Visual Studio's C++ XAML support is limited — relies on build-time .winmd + XamlCompiler output, not live analysis
• C++/WinRT is a smaller fraction of WinUI developers, so pragmatic degradation is acceptable
• The C++/WinRT build chain: .idl → MIDLRT → .winmd → XAML compiler reads .winmd for type resolution

Start with XamlProjectResolver.FindOwningProject() and trace how discovered projects flow into Roslyn loading and XamlResolution. Verify which syntactic features already tolerate classSymbol = null, then check the existing notification path for reduced IntelliSense. Done means .vcxproj projects are recognized, unsupported type-aware features degrade without errors, and the listed syntactic features remain available.