Build AOT demo project on CI

[maxkatz6]

What does the pull request do?

Not sure yet if it's the best way for us to test AOT builds on the CI.
Ideally, we should compile our unit tests with AOT and run them on CI instead.
But for now, building single project with all AOT/trimming errors enabled should be enough.
Continues #15815 (as well as this PR should prevent similar regressions).

What is the current behavior?

If any commit regresses AOT support, including AOT related warnings, nobody might notice until too late.

What is the updated/expected behavior with this PR?

If any commit regresses AOT support, including AOT related warnings, build should fail.

How was the solution implemented (if it's not obvious)?

Re-purposing BindingDemo project as a decent functionality test.

[avaloniaui-bot]

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

[avaloniaui-bot]

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

[avaloniaui-bot]

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

[maxkatz6]

Might not be necessary after #16543

[kekekeks]

Can we run some subset of integration tests with AOT too? e. g. ones that would cover bindings and stuff.

[maxkatz6]

@kekekeks once [GeneratedComInterface] is merged, I was considering to run full set of integrational tests with AOT. We don't rely on reflection there, it should work well.

[maxkatz6]

Closing, as we want to focus on integrational tests in AOT mode instead.