Update “tuple” handling

[Nigel-Ecma]

Addresses issue #1155
Replaces PR #1366

A “surgical” fix for issue 1155 was outlined and later tried in PR 1366 (spun off from an earlier PR), unfortunately it did not work (mea culpa). This PR is the less surgical fix…

• Fixes a number of issues with the description of “tuples” existing prior to issue 1155, and the issue itself
• Split “tuples” into tuple_literal, local_deconstructing_declaration, and deconstructing_assignment to enable fixes and improve clarity
• Split assignment into 4 subrules (rather than just four alternatives) to support above and improve clarity
• Update samples as needed
• Embed HTML comments covering how to update the additions for C#10.

[jskeet]

• Fixes a number of issues with the description of “tuples” existing prior to issue 1155, and the issue itself

Do we have a concrete list of those issues somewhere? Given the size of this change, it would be nice to have a really easy-to-reference list of issues that it fixes.

[Nigel-Ecma]

Here is an overview of the PR (this list is not guaranteed to be complete):

• The syntax pattern ( <item>, <item>, … ) occurs in multiple places in C# with different meanings, e.g. parameter lists and tuples. The original presentation of “tuples” covered three different meanings using a single set of grammar rules and associated text. Unfortunately certain restrictions, such as where a declaration_expression is valid, where omitted in this compound description. By separating out the three meanings into tuple_literal, local_deconstructing_declaration, and deconstructing_assignment the PR addresses these issues using a combination of grammar and text.
• Unfortunately it was not always clear when the described manipulation of tuple constructions was occurring at compile or execution time. The PR addresses this, for an example see §12.7.
• Tuples are (currently?) unique among the language specified compound types in requiring a certain underlying implementation using a family of ValueTuple types (whose underlying implementation is left to the the implementation). The description of this requirement was distributed and incomplete; in particular while all tuples have a unique ValueTuple representation the reverse is not true and how to handle a ValueTuple value which is not equivalent to a tuple was unfortunately omitted. The PR concentrates the relationship into one clause and covers the missing cases.
• The conversions available for tuples was unfortunately incomplete, an issue raised by Tuple conversions are incorrectly specified #1155. This PR addresses this, and some reorganisation and clarification of the material was required to enable this.
• In destructions it was unfortunately not clear what the required order of evaluation of elements was, or whether they even needed to be evaluated.
• For discards it was not clear that they must have a type, e.g. it is invalid as part of a destruction to match a discard to a null as, though the value is unused, the discard has no type.
• The PR adds details on when implementations may elide intermediate tuples while maintaining the defined semantics of the language. For example (a, b) = (b, a); does not require tuple construction and deconstruction.
• Over time the number of uses & meanings of assignment in the language has increased and the text, and particularly the grammar, was unfortunately no longer as clear was one would wish. Tuples and destruction only added to this so as well as adding the new grammar and text required the PR does some reorganisation to clarify the grammar and make the text clearer.
• Overall the PR uses more precise grammar and reorganisaton of the text to improve the clarity of the Standard in this area.

In addition to these other issues were addressed as they came to light during development.