When parsing an identifier as an expression we'll immediately create an
unresolved VariableProxy in the parsing scope. If this variable ends up
becoming a declaration, e.g., due to arrow function parameter, we'll move it
into the function scope for that arrow function. Then to actually create the
declarations we rewrite the "pattern". When we declare the variable, the proxy
is automatically resolved to the variable we create from it. That means it
can't be in the unresolved list anymore.

We tried to remove the unresolved variable. Unfortunately, if there was a
sloppy eval in a parameter context, there's an additional var-block scope
created for the parameter. Rewriting happens in *that* scope. Hence we didn't
always manage to remove the unresolved variable. I suppose as a fix an
additional variable proxy was introduced; since otherwise the implicit
resolution upon declaration would trigger a dcheck in scope resolution later.

This CL removes the initial variable proxy from the correct scope, so it can be
reused for the declaration.

Change-Id: Id917afb177aef076a2947b0fdd03b5393bd29c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1261937Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56402}