Adjust several locations where required types are discussed

[eernstg]

This PR changes several locations in the patterns feature specification where the 'required type' of a pattern is discussed. It adds rules about the required type in some cases where it was left unspecified. In particular, it says that the constant expression in a relationalPattern is type checked with the context type _ (I can't see that we have anything else). The required type of a relationalPattern is kept open (Object?). The actual checks associated with this kind of pattern are performed during the traversal of the pattern, and there is no single type T would would make the same checks occur just by being the matched value type.

The changes include a somewhat controversial part: The definition of "assignable". The new text changes the order of the two bullet points where assignability is discussed: First we check whether there is a need for a coercion, and insert it if needed, and obtain a new M (so M might have been X Function<X>(X) and is now int Function(int)). Next, we check that M is assignable to the required type of the pattern.

This approach is compatible with both definitions of 'assignable' (both the one in the nnbd feature specification and the language specification, and the one that includes coercions): We just don't rely on 'assignability' to take coercions into account, and then it doesn't matter whether or not they are part of 'assignability'. ;-)

Other changes:

I changed all references to primitive equality to use the phrase 'primitive equality'. There are several locations where 'operator ==' is mentioned specifically, and some of them have been preserved, because it was actually specifically about this operator.

I added a few words to indicate that 'pattern type checking' can include provision of missing parts (so [var j] could be transformed into <double>[var j] at this time, based on M).

[stereotype441]

lgtm assuming some clarifying informative text is added, see my comment.

[munificent]

This looks great. Thank you for clarifying it!

[eernstg]

Review response.

The paragraph about type checks applied to relational expressions had to be rewritten extensively, because of the ordering dependencies (e.g., we need to find the operator and the type of the operator parameter before we can type check the constant expression).

I used the text from @stereotype441 as a starting point for a small section about coercions.

I've weaseled around the distinction between the two models (coercion == transformation of an expression in-situ, vs. coercion == semantic step where the same operation is performed, but presumably on a temporary variable which is a built-in property of the semantics of the given pattern matching, assignment, etc.).

[eernstg]

Thanks for feedback!

@lrhn, do you have further comments?

[eernstg]

Review response

[eernstg]

Review response.

I don't think we're in a position to introduce a notion of "promoted matched value type after failed match" with || patterns. Otherwise I think the issues have been resolved.

[munificent]

Still LGTM.

[eernstg]

Latest review response: Logical-or patterns now do require promotions based on a failing match in the first operand to be taken into account.