Document Restrictions::NO_STRUCT_LITERAL better

[ehuss]

The Restrictions::NO_STRUCT_LITERAL restriction could be better documented. Currently we have:

• Various places in the grammar say _except [StructExpression]_ to show where this limitation goes into effect.
• expr.struct.brace-restricted-positions briefly touches on it.

This restriction has the consequences in the following examples:

// This is parsed as `S` as the condition, followed by the consequent block, followed by an empty block.
// Fails because `S` is a type, not a bool value.
if S{} {}

// This is parsed as `x==S` as the condition, followed by the consequent block, followed by an empty block.
// Fails because `S` is a type, not a value.
if x == S{} {}

// This fails to parse because colons are not valid syntax in a block.
if S{field1: i32} {}

This was introduced with RFC 92.

Various things to consider:

• Need to double check that the existing parts are covered correctly and completely.
• Make it clearer how this is a "sticky" state, and that this state gets reset or removed in various places.
  • One particularly odd part is parse_expr_opt which drops all restrictions.
  • Where this restriction "ends" probably hasn't been done intentionally (or at least with broad awareness), so we'll need to decide what should be documented.
• It would be good to link the _except_ grammar suffixes to expr.struct.brace-restricted-positions.
• It might be good for expr.struct.brace-restricted-positions to have a note explaining why the restriction exists, and to show an example.

I do not think it is practical to encode this in the grammar, though others may disagree. Essentially we'd have to duplicate the majority of the Expression grammar with things like ExpressionNoStructLiteral, and duplicate every sub-rule. I'm concerned that would be duplicating a huge amount of the grammar, but also that it is not sustainable since there are other restrictions that would cause an explosion of permutations.

See #569 for the previous issue for this.