Surprising parse result when using attribute with `&` in expression and clashing name

[bbannier]

This might be more a documentation of current behavior, but if one passes an expression involving & as an attribute value, and the RHS of the & clashes with an attribute name we interpret & and the following string as the next attribute.

module foo;

global a = 1;
global size = 1;

public type X = unit {
    x: bytes &size=1&a { assert |$$| == 1; }  # Works.

    y: bytes &size=1&size { assert |$$| == 1; }
                  # ^ E: &size must provide an expression
                  # ^ E: attribute &size requires an expression
};

The Spicy parser can distinguish these since it hardcodes all possible attribute values. If users want to write similar code they could avoid names which clash with current attribute names, but since we might add more attribute names in the future the safest approach would be to instead precompute the expression (e.g., in a global or unit variable) and pass that to the attribute. If complex expressions depending on the parsed value need to parse, e.g., imagine a field

y: uint8[] &until=$$&a;

one can move $$ & a to a function.