Fuzzing for stable stringification

[Adjective-Object]

Adds fuzzing tests for Parse / .JS() to validate the following:

• repeated .Parse() followed by .JS() produces a stable AST
• .Parse() followed by .JS() will not crash for any input

Fuzz saves these testcases to the testdata/fuzzfolder and adds them to the normal test run.

To discover more failing cases, run

• go test -fuzz FuzzIdempotent ./js

As part of this I fix, I also address some idempotency issues in existing test-suites and things I found with some short fuzzing:

• case statements that would produce an unstable AST. It looks like a near-dupe of the issue addressed in 9d9c40e21e185813ef998145f0d0e93eceff20a1
• if() with an empty statement instead of a block statement would not produce an unstable AST (also a near-dupe of 9d9c40e21e185813ef998145f0d0e93eceff20a1)
• if() with a labelled empty statement would produce an invalid AST, because it would parse as a label with no following statement
• parse would not error on an invalid variable binding pattern (A,{}%0%{})=>0"
• Newlines following throw would not error during parsing (this is illegal). This caused a throw with no expression to be inserted into the AST, which would crash on stringification.
• dot expressions on numeric literals 0 .toString() would stringify to 0.toString(), creating an invalid numeric literal
• binding expressions with invalid inputs would not error
• binding expressions with nil final elements would not serialize stably (each iteration they would drop another comma, since
  • the parse step correctly interprets a trailing comma as an extra comma after the final element
  • the serialize step was omitting the trailing comma after the final element
  • when the final element serialized to an empty string, the non-trailing comma omitted during parse was interpreted as a trailing comma
• binding expressions with invalid left-hand assignment in an equals expression were not erroring correctly
• Name serialization of class members was incorrectly using .String() in a .JS() call, which lead to unstable serialization of class member names.

Note that this is probably not the end of fuzzing errors. I've only been able to fuzz for up to 5 minutes at a time before finding a new failure.

Related to the discussion in #108

[tdewolff]

I'm very sorry for the extremely late response. This PR had completely slipped the radar. Thank you very much for this contribution, it contains some valuable bug fixes. Fuzzing going back and forth with JS() is a good idea.

Instead of merging, I've completely restructured the ast.go code base (reducing code duplication and superfluous error checking). See 38da6d49822b37d16bc1ab1caa08a168db3c0e55. You should use ast.JSString() to get a string, or otherwise use the JS(io.Writer) interface on all nodes. Similarly for JSON.

I've also added the fuzzing script together with the other fuzzers in tests/ so that they are run automatically with OSSFuzz periodically. Your bug fixes have been incorporated with the following commits: bf2964b45b940153f1cc46df11da34889da7c7e6 9b8eaa4f0272c227e3edfa6fef37f8515a92cf71

I believe the changes in this PR are thus incorporated and I'll close this PR. I'll keep adding fixes for crashes found with fuzzing, thanks again for the effort!!

[tdewolff]

Just wanted to follow up that your idea was a tremendous source for discovering bugs in the JS output and in the JS parser itself! I get at least 2 new bug each week, thanks again!