…ing AST nodes (#22972)

Closes: #22934

Alternative to #22934.

### The problem

`check_function_redeclaration` (the Annex B.3.3 legacy duplicate-function rule) distinguished a plain `FunctionDeclaration` from an `async`/generator one by reading the _previous_ declaration's AST node through its stored `NodeId`:

```rust
let prev_function = ctx.nodes.kind(prev.declaration).as_function();
if prev_function.is_some_and(|f| !(f.r#async || f.generator)) { return; }
```

That node is a popped sibling (not an ancestor of the current node), so it's the last build-time read that would prevent making AST node storage optional.

### Starting point

In real-world code, no-one uses function redeclarations. They are completely pointless. We only need to handle this case to be conformant with the spec, just to be able to say we're conformant with the spec.

Further, the specific circumstances in which this Annex B rule applies are even more rare. All the following must be satisfied:

- Sloppy-mode code.
- Function redeclarations in a nested block (not top-level or nested in another function).
- JS not TS.

Therefore, we can assume the code which handles this case is unreachable in practice. The priority is to make recording the data required for the check as cheap as possible - in terms of perf, and memory usage.

### How

Record the one bit of information we need at bind time, while the node is still in hand. When binding an `async`/generator function declaration in a sloppy-mode block, push its `NodeId` into a `Vec` on
`SemanticBuilder`. The check then answers "was the previous declaration async/generator?" by searching this `Vec`.

The check only applies in the specific circumstances listed above. So don't push values to the `Vec` in modules, strict mode, top-level code, or TypeScript. In practice, the `Vec` will always remain empty.

The checking code in `check_redeclared_function` does a linear scan of the `Vec`, which is expensive, but as function redeclarations in nested blocks in sloppy mode JS are vanishingly rare in real-world code, this doesn't matter.

Additionally, improve the errors when a violation _is_ found - the error points to the offending `async`/generator function, rather than stopping at the immediately preceding declaration. That only adds diagnostics on code that was already invalid - conformance is unchanged.