The decoder should not pollute a global scope unless it's fine

[lifthrasiir]

The decoder should not pollute a global scope unless it's fine

[lifthrasiir]

I've experimented with multiple implementation strategies:

• Insert delete VARIABLE;s at the beginning of the input. This turned out to be unworkable if the variable was only used locally and got hoisted (delete f; function f() { ... } will be incorrect for example). So this workaround only works when we do the escape analysis, which is unreasonable for Roadroller.
• Insert delete VARIABLE;s right before the actual eval. This is less invalid than before but still can cause a problem if there is other uncompressed code around. I'm not sure if we should support this mode or not though.
• eval(((A='COMPRESSED DATA', VARIABLES...) => { VAR=INIT; ...; return c })()) was very lengthy.
• eval(eval("let A='COMPRESSED DATA'," + [...'VARIABLES'] + "; VAR=INIT; ...; c")) avoids return but VARIABLES should be unique, limiting the optimization possibility. A variant using var would allow duplicates but pollutes the global scope.
• eval(Function("A='COMPRESSED DATA'", ...'VARIABLES', "VAR=INIT; ...; return c")()) still has the same problem but seems to be a bit smaller.
• eval(Function("A='COMPRESSED DATA'", ...'SOME VARIABLES', "VAR=INIT", "...; return c")()) combines initial assignments with argument definitions.
• eval(Function("[A='COMPRESSED DATA'", ...']VARIABLES', "...; return c")([], INIT...)) eliminates initial assignments by reusing arguments. The first variable has to be undefined, hence a weird argument definition (translates to [A=...,],V,A,R,I,A,B,L,E,S). This seems to be the best alternative so far, only ~25B larger than before. (But see below.)

Some of these experiments required another variable renaming, and honestly I'm sick of it. So the next step is to make variable names fully configurable.