PreserveImportsExportsJS Fuzzer: Fix reduction

[kripken]

This fuzzer generates its own files, so reducing it needs some hacks,
unfortunately. Another option might be to separate this fuzzer out
entirely to its own file, or to at least not run multiple fuzzers on the
same testcase (see below), but I'm not sure those are better options.

When the main fuzzer runs multiple internal testcase handlers on a
single wasm file, we must make sure while reducing that only
PreserveImportsExportsJS receives its wasm. That wasm only works
with its JS, so other fuzzers will fail on it. To do so, use an env var
BINARYEN_PIEJS_WASM which tells the fuzzer we are reducing
in such a situation. The fuzzer reduction script then passes in the
reduced file that way, rather than the usual way, so other fuzzers
do not notice it.

Also rename orig.wasm to initial.wasm as this was confusing
given that reduction always starts from original.wasm.

[aheejin]

Haven't read this all yet (I've got to go now) but a typo.
(In case another person LGTMs it don't wait for me)

[aheejin]

BINARYEN_PIEJS_WASM is a file name and not 0/1, based on the code below

  BINARYEN_PIEJS_WASM={temp_wasm} ./scripts/fuzz_opt.py {auto_init} --binaryen-bin {binaryen_bin} 

[tlively]

As an alternative approach, how about we give the fuzzer options to say what fuzz handler to run? Then the reducer script can specify exactly the failing handler. This would be useful for manual investigations as well. A tricky bit is that random choices in one handler should never be affected by previous handlers so that reducing the number of handlers executed does not change their behavior. This could be done by snapshotting the random state before executing each handler and restoring it afterward.