Go-to-definition on `await`/`yield` should probably jump to the containing respective async function/generator

[DanielRosenwasser]

Similar to #51222.

async function outerAsyncFun() {
  let af = /*END*/async () => {
    /*START*/await Promise.resolve(0);
  }
}

function* outerGen*() {
  /*END*/function* gen() {
    /*START*/yield 100;
  }
  return gen
}

We should probably do nothing in cases like top-level await, or where await does not have a direct corresponding async function, and yield does not have a direct corresponding generator.

[fatcerberus]

I would expect GTD on await to jump to the async keyword of the containing function, in line with how e.g. VS C# intellisense highlights the async keyword (and incidentally, all the other awaits in the same function) when you place the cursor on an await.

[DanielRosenwasser]

I guess maybe there's a catch with

class Foo {
  /*END1*/public /*END2*/async yadda() {
    /*START*/await 10;
  }
}

I feel like the distance is not that big that it matters whether we pick END1 or END2. I could go both ways.

Thinking about it some more, I wonder if it makes sense to always make the go-to-definition succeed, even if the containing function isn't async or a generator. If you're in the error case, it can be helpful to jump to whichever function contains the keyword.

[DanielRosenwasser]

Also, another fun test case based on the "should not fail" strategy".

function* gen() {
  /*END(???)*/class C { [/*START*/yield 10]() {} }
}