Store attribute access and call args on reference expressions

[stasm]

Right now, we store complex member expressions as nested trees of AST nodes. As an example, a parameterized term attribute of the form -term.attr(arg: "value") parses as:

CallExpression {
    callee: AttributeExpression {
        ref: TermReference {
            id: Identifier {name: "term"}
        },
        name: Identifier {name: "attr"}
    },
    positional: [],
    named: [NamedArgument {...}]
}

This is a well established pattern in general-purpose languages. It is capable of handling deeply nested hierarchies of expressions. In Fluent, however, we only ever go so deep. All the possible nestings are known up-front and are defined by the grammar.

Furthermore, the above AST structure makes tooling harder. Checking for a TermReference means checking for four different AST structures (corresponding to -term, -term(), -term.attr, and -term.attr()).

In this PR, I've tried a different approach: the attribute access and the call arguments are stored on the reference node itself:

TermReference {
    id: Identifier {name: "term"},
    attribute: Identifier {name: "attr"}
    args: CallArguments {
        positional: [],
        named: [NamedArgument {...}]
    }
}

I implemented this approach for MessageReference, TermReference, VariableReference and FunctionReference.

[stasm]

CallArguments is a separate SyntaxNode for two reasons:

1. The tooling parser can store the span of (...) on it.
2. In TermReference, the args field is nullable. This allows us to distinguish between -term and -term(), which are functionally the same, but require different serialization.

[stasm]

Naming things... attribute or attr to make it consistent with id and args?

[Pike]

Full name sounds about right to me. attr is less obvious about the fact that this is exactly one or none.

[Pike]

I like this. In particular the ease in abstract.mjs is nice, I've struggled with reviewing the Term.attr the first time around.

There's a nit about left-overs in abstract.mjs for AttributeExpression, make that 💥 ?

Independently of the r=me, we should talk about when to do this.

[Pike]

Full name sounds about right to me. attr is less obvious about the fact that this is exactly one or none.

[stasm]

There's a nit about left-overs in abstract.mjs for AttributeExpression, make that 💥 ?

Ah yes, thanks, I forgot about that part.

Independently of the r=me, we should talk about when to do this.

I think we should do this in 0.9, perhaps after #214 lands, so that we don't have to deal with VariantExpression any longer.