Consider forbidding pass-through `.local`

[eemeli]

So here’s an interesting detail that I needed to puzzle through while working on the JS Intl.MessageFormat spec text:

In a message like

.local $foo = {$bar}
{{{$foo :func} and {$bar :func}}}

we do not guarantee that :func will be called twice with the same inputs, effectively because of this line of the Expression Resolution part of the spec:

An implementation MAY perform additional processing when resolving the value of the expression.

In other words, what looks like a no-op assignment isn't, because we allow for implementations to effectively apply any transforms to expressions that don't have an annotation.

Given that we do have .input, is there a use case for allowing just {$bar} as the .local value? I do see the value in allowing for a bare literal value to be used like .local $foo = {some-keyword}, but even then requiring something like :number or :string on it doesn't seem like it would be too much to ask.

The benefit of this change would be to pre-empt a potential source of confusion, as it's not clear to a reader that the $foo and $bar values above can be of completely different types.

This disambiguation isn't needed for .input, as it is establishing a single definition within the message for its variable reference, so .input {$foo} should still be allowed.