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

tc39 / proposal-extractors

Add NLT to ExtractorBindingPattern and ExtractorMemberExpression #25