Document and test the runtime XAML namespace fallback

[wieslawsoltes]

Summary

• reproduce the previewer/runtime XAML namespace failure reported in XmlnsDefinition not found #325
• document an explicit assembly-qualified namespace fallback
• prove that the fallback coexists with application-defined XmlnsDefinition mappings
• add focused runtime-compiler regression coverage

Investigation result

The behavior packages already contain the expected assembly-level XmlnsDefinition attributes. Normal compiled XAML resolves Interaction, EventTriggerBehavior, and the other mapped types correctly.

The reported error is reproducible in Avalonia's runtime XAML compiler (the same path used by the previewer), including the Unable to resolve type Interaction and ResolveContentPropertyTransformer diagnostic cascade. The runtime compiler builds its XML namespace map from assemblies loaded when its static compiler context is initialized. If the behavior assemblies have not yet been loaded, their otherwise-correct attributes are absent from that cached map.

Application-defined XmlnsDefinition attributes are not themselves invalid; they expose the runtime-loader ordering because the application assembly is available while external behavior assemblies may not be.

Why this PR uses a compatibility fallback

This initialization and assembly-discovery behavior lives in Avalonia's runtime XAML loader, outside the behavior package. Changing or duplicating package attributes cannot update a namespace map that the host created before loading those assemblies.

The reliable package-side guidance is to use assembly-qualified CLR namespaces in views affected by the previewer/runtime-loader path. Explicit assembly names make the compiler resolve the required behavior assemblies directly.

Changes

• add a previewer/runtime-loader troubleshooting section to the XML namespace documentation
• show explicit mappings for:
  • Avalonia.Xaml.Interactivity in Xaml.Behaviors.Interactivity
  • Avalonia.Xaml.Interactions.Core in Xaml.Behaviors.Interactions
• clarify that focused packages such as custom interactions should use their owning assembly
• add a custom XML namespace mapping to the test application assembly
• add a runtime XAML loader test combining that application mapping with explicit behavior assembly mappings
• add the runtime loader package only to the test project

Validation

• first confirmed that the same runtime test fails with the default namespace and produces the issue's exact resolution errors
• dotnet test tests/Xaml.Behaviors.Interactions.UnitTests/Xaml.Behaviors.Interactions.UnitTests.csproj --filter 'FullyQualifiedName~XmlnsDefinitionRuntimeXamlTests' --no-restore
  • 1 passed, 0 failed
• dotnet test tests/Xaml.Behaviors.Interactions.UnitTests/Xaml.Behaviors.Interactions.UnitTests.csproj --no-restore
  • 90 passed, 0 failed, 2 pre-existing skipped drag tests
• git diff --check

Closes #325