Rework XAML compilation targets

[MrJul]

What does the pull request do?

This PR reworks the MSBuild targets in AvaloniaBuildTasks.targets, responsible for compiling the XAML files into the final assembly.

A bit of history

Before #13840, the original intermediate assembly (in the obj folder) was effectively patched in place (with a copy of the original one kept around).
This regularly caused some file access issues in parallel builds. It also made MSBuild think that the output was always changed between builds, effectively killing incremental builds.

After #13840, the original intermediate assembly is preserved, and the XAML compilation target outputs a new assembly instead. The intermediate assembly path is updated to the new one after the compilation.
At the time of that PR, this sounded like a good idea, preventing all the issues mentioned above.

However, this triggered a cascade of issues. Anything that relied on the intermediate assembly without triggering compilation was effectively broken, finding the old assembly instead.
This included NativeAOT, ClickOnce, publishing without building... Each subsequent fix triggering new failures in seemingly unrelated areas. For example, we've had #16835 re-trigger XAML compilation for --no-build publish, effectively breaking Android release builds which rely on publish targets implicitly, causing double compilation...

How was the solution implemented?

What if instead we could have XAML compilation be part of the "standard" compilation (the CoreCompile target, responsible for running the C# compiler)?

That's possible with the TargetsTriggeredByCompilation property.
Any target referenced by this property will run as part of CoreCompile. We're free to modify the intermediate assembly here, since we didn't effectively "return" it from the target yet.

We also need to add the XAML files as inputs to that target, which is doable using the CustomAdditionalCompileInputs items.

With these changes, the target's logic is greatly simplified, and just naturally works, both for full rebuilds and incremental builds.

Build tests

It was getting quite hard to ensure that we didn't regress anything while editing these targets.

To solve that, this PR introduces a new BuildTests solution, outside of the main one.
As part of CI, BuildTests is built using the NuGet packages that have just been generated from the main build. This ensures we're mimicking a standard user's solution as much as possible.

Output assemblies of the various build tests are then checked to ensure they correctly contain compiled XAML.
This is done for:

• Standard C# platforms (Desktop, Android, iOS, Browser)
• publish --no-build
• NativeAOT
• A WPF app containing both WPF and Avalonia XAML files
• A F# project

Fixed issues

• Supersedes Fix "original.dll" file permission errors during build #13840
• Supersedes Fix NativeAOT not using the XAML compilation output #14966
• Supersedes Fixed NativeAOT on .NET 9 #15705
• Supersedes Fix --no-build publishing when axaml compiler is used #16835
• Supersedes Fix ClickOnce entry assembly not having Avalonia XAML compilation output #17115
• Supersedes Fixed publishing multi-architecture Android builds #17145
• Fixes InjectAvaloniaXamlOutput appears to mangle property IntermediateAssembly on multiple runs and prevents trimming #17099

[kekekeks]

Note that the original issue can't be reproduced with a plain dotnet build, with Rider it was only happened when one tries to debug the app.

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0053376-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[TomEdwardsEnscape]

That's possible with the TargetsTriggeredByCompilation property.
Any target referenced by this property will run as part of CoreCompile. We're free to modify the intermediate assembly here, since we didn't effectively "return" it from the target yet.

Fantastic! Wish I'd know about this at the start.