Correctly handle variables introduced in switch scopes

[lukastaegert]

In Javascript, switch statements introduce a local scope which means that variables can be re-declared inside of them. This pull request implements this behaviour and includes several test cases. To illustrate:

Test cases:

const x = globalFunction;
function y () {}

switch ( anotherGlobal ) {
  case 1:
    const x = function () {};
    x();
}

switch ( anotherGlobal ) {
  case 2:
    x();
}

switch ( anotherGlobal ) {
  case 3:
    const y = globalFunction;
}
y();

switch ( globalFunction() ) {
  case 4:
}

Previous output:

const x = globalFunction;
switch ( anotherGlobal ) { // Could have been removed as there are no side-effects
  case 1:
    const x = function () {};
    x();
}

switch ( anotherGlobal ) {
  case 2:
    x();
}

y(); // This is REALLY bad!

switch ( globalFunction() ) {
  case 4:
}

Output after this pull request:

const x = globalFunction;
switch ( anotherGlobal ) {
  case 2:
    x();
}

switch ( globalFunction() ) {
  case 4:
}

As a little background about me, I have recently completed an ESLint plugin that will flag code that is not tree-shaken by rollup due to side-effects:
eslint-plugin-tree-shaking

Writing this plugin--which basically implements a side-effect detection algorithm similar to yours--gave me some insights as to how your algorithm might be improved in the future. This pull request is the one that was easiest to implement, others would require greater refactorings.

If you are open for these kinds of contributions, I would be very interested in discussing my ideas and possibly making more pull requests.

[Rich-Harris]

Thank you! This looks great. You're quite right, the scope handling is a bit wonky at the edges — I've gone and messed up #1517 by merging a PR that causes a conflict, bear with me...

Certainly interested in ways that the algorithm could be improved. I suspect we need a fairly substantial rewrite to fix certain things — I tried this once, but didn't manage to finish the work before it became impractical to merge — but there might well be smaller fixes that we can do in the meantime.

[lukastaegert]

Actually, instead of doing a big rewrite I think a lot can be accomplished by a chain of moderate refactorings like #1517. I have a lot of ideas how to better handle e.g. instantiating classes, mutating function parameters or handling reassignments. When I am back from my current vacation I might make some more PRs for this.