proposal-extractors Add NLT to ExtractorBindingPattern and ExtractorMemberExpression

This adds a [no |LineTerminator| here] assertion to ExtractorBindingPattern and to ExtractorMemberExpression and introduces a new [Assertion] production parameter to ExtractorMemberExpression to align with Option (1) as discussed in #24:

Introduce an NLT in ExtractorBindingPattern but not ExtractorAssignmentPattern.

This is an alternative solution to the one implemented in #27.

The outcome of this change is as follows:

For
```
let x
(a) = b
```
the source is interpreted as let x; (a) = b; due to the NLT assertion and ASI.
For
```
let x
[a](b) = c
```
the source is interpreted as let x; [a](b) = c; due to the NLT assertion and ASI. Note that [a](b) is not a valid ExtractorAssignmentPattern as [a] is not a valid ExtractorMemberExpression and will result in an Early Error when applying static semantics for destructuring assignment.
For
```
let x[a]
(b) = c
```
the source is interpreted as let x[a]; (b) = c; due to the NLT assertion and ASI and results in a Syntax Error at parse time.
For
```
x
(a) = b
```
the source is interpreted as x(a) = b; as there is no NLT restriction. This makes ExtractorAssignmentPattern mildly inconsistent with ExtractorBindingPattern.
For
```
x
[a](b) = c
```
the source is interpreted as x[a](b) = c; as there is no NLT restriction. This makes ExtractorAssignmentPattern mildly inconsistent with ExtractorBindingPattern.
For
```
x
[a]
(b) = c
```
the source is interpreted as x[a](b) = c; as there is no NLT restriction. This makes ExtractorAssignmentPattern mildly inconsistent with ExtractorBindingPattern.

Fixes #24 Related #27

May 28 '24 19:05 rbuckton

A preview of this PR can be found at https://tc39.es/proposal-extractors/pr/25.

May 28 '24 19:05 github-actions[bot]

Closed in favor of #27

Sep 26 '24 20:09 rbuckton