Multiple `var` for the same binding should not be added in one function/module scope about add-variable-declarations HOT 1 CLOSED

I'm working on this (and also decaffeinate/decaffeinate#605 ), and it turns out to be a pretty significant change to this project, so I guess I'll write down some notes of my plan in case I'm overlooking a better way:

• Rather than ever doing magic-string operations while traversing the tree, the new plan is to maintain tentative information about all bindings, which might change as we discover more information, and then only "commit" those bindings at the end (or, at least, when we know they won't change anymore).
• Each of these tentative binding objects is "owned" by some function (or program) scope (really some TraverseState with a function scope), even if we end up adding the var in a more specific scope. That means we won't miss declarations within if statements (fixing decaffeinate/decaffeinate#605 ) and lets us know that two variables are the same for the purpose of finding the most specific scope.
• As we see variable declarations and usages, we traverse up to the enclosing function scope to find the latest binding information, then update the "most specific scope" information to the lowest common ancestor of the two.
• In cases where we'd prefer to do an inline declaration (e.g. a destructure), we only end up doing so if none of the assigned variables ended up moving to a parent scope.

from add-variable-declarations.