Added support for x:Array extension, including inline syntax

[jp2masa]

Changes

• Added support for x:Array extension, including inline syntax.

Use cases

x:Array as in WPF isn't really useful I believe, as it can be easily replaced by list property setters. My main interest is the inline syntax (which doesn't exist in WPF), example:

{x:Array 0, 1, 2, Type={x:Type x:Int32}}

Passing constant data

Data="{x:Array 5, 7, 1, 2, Type={x:Type x:Int32}}"

Markup extensions (including multibindings)

For example, if MultiBinding (in Avalonia) was a markup extension it could be possibly used like this:

Text="{MultiBinding {x:Array {Binding FirstName} {Binding LastName}, Type={x:Type IBinding}}, StringFormat='Hello, {0} {1}!'}"

I also investigated the possibility of handling params parameters, but that would be much more work, and this syntax is already considerably more readable in my opinion.

[maxkatz6]

There is active proposal in WinUI repo to introduce new arrays syntax in XAML.
https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/gridsyntax/GridSyntaxSpec2.md#other-use-cases

It can cover cases with inline arrays.
Although, this proposal isn't yet implemented and not in the MS-XAML specification. So it can be ignored for now.

[jp2masa]

That looks interesting! I don't think it would solve my problem though, which is passing an array to a markup extension.

For example, if there were 2 constructors, MyExtensionExtension(string str) and MyExtensionExtension(string[] str), which one would be resolved for {MyExtension 'a, b'}?

In markup extensions particularly, the constructor is resolved from the exact parameter types of the values, so the type of 'a, b' would have to be resolved before anyway. The same applies for x:Args I believe, although it's rarely used.

The closest scenario with the proposal would be {MyExtension Elements='{Binding X}, {Binding Y}'}, but I think that's not covered by the spec.

[kekekeks]

We need to trigger an error for unhandled nodes, otherwise they will be silently ignored.

[kekekeks]

The current policy is to have a separate emitter class rather then implementing IXamlAstEmitableNode. That's needed because of the planned C++ emitter backend for UWP.