Allow VariableReference as NamedArgument value

[eemeli]

• Closes Allow all inline expressions as named arguments #230
• Closes We should add a fixture test that verifies that only strings or numbers can be values of NamedArgument #325
• Closes reusing terms to create more complex terms #337
• See also Let's reduce the gap between Fluent and MessageFormat 2 #349
• Closes Forward all variables to parameterized term #369

This proposed syntax change would require the release of a new Fluent version, probably 1.1. It's forwards-incompatible, i.e. while all Fluent 1.0 content is valid Fluent 1.1, not all Fluent 1.1 content would be considered valid by a Fluent 1.0 processor.

Effectively, this would allow for usage like:

-term = the { $foo } term
msg-1 = This message includes { -term(foo: $term) }.
msg-2 = This message formats { NUMBER($n, minimumFractionDigits: $fd) }.

Not all inline expression values are supported as named arguments, so e.g. { -term(foo: -bar) } would continue to be a syntax error. My sense is that the strong, active desire is only for variable references, and that other uses are much more limited.

I'll be sumitting PRs for fluent.js and python-fluent to showcase the impact on implementations. From #325 I gather that fluent-rs might already support this, or that it's likely to be relatively straightforward to add there.

We'll need to consider carefully how to handle this in Pontoon, as we may need a per-project configuration of the supported Fluent version, or we need a solution for #208.

In Firefox, we'll need to review the capabilities of the fluent-rs version we're using.