fix: Class Field Initializer should not allow await expression as immediate child

[JLHwung]

Q	A
Fixed Issues?	Fixes #6687
Patch: Bug Fix?	Yes
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This PR fixes the isAwaitAllowed logic by excluding await identifier reference immediately nested in a class property initializer.

Per https://tc39.es/proposal-class-fields/#sec-new-syntax

FieldDefinition[Yield, Await]:
   ClassElementName[?Yield, ?Await] Initializer[In, ~Yield, ~Await]opt

the spec dictates that the Initializer can not contain IdentifierReference_Yield or IdentifierReference_Await, which means await should be considered as identifier reference here, unless its [Await] parameter is enabled by other language structures.

The original snippet in #6687

async function a() {
  class Foo {
    bar = await baz();
  }
}

will still throw because await is an identifier instead of await expression, but not because the constructor is not an async function. Think of the following example, which should still throw even the static property does not need a constructor to initialize.

async function a() {
  class Foo {
    static bar = await baz();
  }
}

Note that we have a similar issue regarding to the generators:
Parsing the following code should throw because yield is an identifier, which turns out to be a reserved word since it resides in a class declaration where all parts are in strict code mode.

function* f() {
  return class { p = yield + 42 }
}

I will address this in a separate PR.

[nicolo-ribaudo]

Do we have tests for await inside computed keys? I tried searching [await but couldn't find them.

async function f() {
  class A {
    [await 1]() {}
  }
}

[JLHwung]

@nicolo-ribaudo Test is added. The computed properties are not affected here because it is never in the class scope. The class scope are applied to the property initializer and the method body.

But I feel like if we really want to be 100% spec compliant, we should introduce noAwait and noYield as acorn did in noIn, and align these context states to the grammar. Checking noAwait via scope and awaitPos still looks ad-hoc to me.