Fix shadow function processing for async functions

[loganfsmyth]

This reverts and re-implements some of the work done in #3336 because while that fixed the rest params, it broke the ability to use arguments in your own code, since it would resolve to the arrow function rather than the outer function.

Also fixed https://phabricator.babeljs.io/T7108

Will squash if people feel like it, but I'd love to keep this split up to it's easier to follow. Not sure what the policy is specifically for non-work-in-progress commits.

[loganfsmyth]

Scoping shadowing is a bit....complicated right now to say the least. I didn't realize quite how hairy it was until I had to dive in for this. I ended up writing all this up for myself and figured I might as well include it.

[sebmck]

Yeah... it's gotten pretty out of hand. It used to be a simple flag then it's use was overloaded (rightfully so since it's within scope, the API is just bad).

[hzoo]

Snap! I don't think we really have a policy on commits - I don't really like the random/merge commits but none of it is really a big deal for me at least (we don't have a commit format atm either)

[codecov-io]

Current coverage is 87.62%

Merging #3405 into master will decrease coverage by -0.20% as of de21f2e

@@            master   #3405   diff @@
======================================
  Files          217     217       
  Stmts        15253   15253       
  Branches      3126    3128     +2
  Methods          0       0       
======================================
- Hit          13396   13365    -31
- Partial        594     624    +30
- Missed        1263    1264     +1

Review entire Coverage Diff as of de21f2e

Powered by Codecov. Updated on successful CI builds.

[sebmck]

We should use the t.is helpers here, at least for consistency. We should seldom touch .type.

[jmm]

We should seldom touch .type

Can you expand on why that is? So it's more abstracted in case node types change? There've been cases where I've thought about going either way and I'd like to learn why the helpers are preferable.

[jmm]

I haven't looked at these commits, but in general:

• I like logical commits. If something makes more sense in the history as separate commits I'm all for it and not in favor of squashing them arbitrarily just because they're in the same PR.
• When tests are being added for something that was broken I like it when failing tests are committed and then fixes so you can checkout commits and see the tests fail then check out subsequent commits and see them pass.
• When fixing mistakes in the PR commits (lint errors, typos, etc.), incorporating feedback, iterating after the PR is opened, I think it's usually good to rebase and squash those with the commit they would've originally made sense in (by the time it's merged anyway).

[amasad]

did you mean "shadows arguments but not this"? Since it's {this: false}