Custom functions with scope access

[PPakalns]

Tries to temporary solve complex translation cases mentioned in:
#268
projectfluent/fluent#80

1. Support user implemented custom functions that can access current scope, can work as Message references.
   In future we could allow access in custom functions to additional information about current scope (developer arguments, local arguments, current errors)
   Message references are highly needed for more complex translation cases with a lot of possible message combinations.

2. Additionally allow using expressions inside named arguments.
   (It looks like by default fluent doesn't allow it Playground )
   This functionality can be placed under boolean flag if we do not want to enable it by default.

See examples included in added tests.

Would like to get feedback if these changes can be upstreamed to fluent-rs.

[PPakalns]

Ping.

[alerque]

@zbraniecki or @waywardmonkeys (or any other maintainers) has anybody had a spare minute to give this a quick gander?

[zbraniecki]

Ehh, some of that is by design (@stasm may remember more on why we didn't want to allow for expr inside named arguments).

Message References are desirable feature, but are non-trivial to implement and I'd prefer to implement them in line with how @eemeli is planning to support them in MF2.0. @eemeli - can you look at the tests in this PR and comment on the alignment?

As for the code - I only skimmed through and I do hope that we can improve the impl before we land this. My recommendation would be to take more time on this and not try to rush it.

[eemeli]

This seems pretty well aligned with MF2's custom functions, which is how it allows for something like messages references. I do have some concern about a general-purpose MSGREF() being potentially more difficult for translators to work with compared to more specific functions like HERO() or CREATURE() that can be much more precisely defined.

Also, splitting up a message like the example hero-owns-creature into chunks makes it more difficult to translate as a whole, prohibits allowing "owns" to vary depending on the creature type, and quite easily leads to unexpected whitespace in languages like Chinese or Japanese that don't use it. So while the approach is technically sound, there are some potential footguns here that ought to be accounted for.

[PPakalns]

Also, splitting up a message like the example hero-owns-creature into chunks makes it more difficult to translate as a whole, prohibits allowing "owns" to vary depending on the creature type, and quite easily leads to unexpected whitespace in languages like Chinese or Japanese that don't use it. So while the approach is technically sound, there are some potential footguns here that ought to be accounted for.

1. You can use MSGREF to lookup creature type and use that as switch/case variable to pick correct "owns" version (In the same way as it is done with HERO gender in the example). Can not comment about whitespace.

hero-owns-creature =
    { MSGREF($hero) } arrived! 
    { MSGREF($hero, "gender") ->
        [feminine] She owns
        [masculine] He owns
        *[other] They own
    }
    { MSGREF($creature, count: $count) }

Sounds good not to rush with final implementation :)