Improve ESTree compliance

[adams85]

This PR aims to improve compliance with the ESTree specification.

Besides what have been discussed here, I made an attempt to address a few further issues:

• In our AST model we don't have separate BinaryOperator/LogicalOperator and UnaryOperator/UpdateOperator enums as specified by the standard but have the separation w.r.t. the corresponding node types (BinaryExpression/LogicalExpression and UnaryExpression/UpdateExpression). However, there were no checks in place to prevent instantiation of these types with a wrong operator type (e.g. a LogicalExpression with a multiplication operator.) Thus, checks have been added to prevent invalid combinations.
• The standard defines special cases (subclasses) for regex and bigint literals. In the case of bigints, I don't think we'd gain anything from a subclass since we don't really have additional data to store (the bigint property defined by the standard can be replaced with a simple literal.BigIntValue.ToString() call in our current model). However, adding a subclass for the regex case seems beneficial as it's a cleaner design and reduces the memory footprint of the AST a bit. (As a matter of fact, we may also consider changing RegexValue and TemplateElementValue to readonly struct records to save a few further allocations.) I'm not sure about this change though, its impact on existing codebases might be more than acceptable. Please let me know how do you feel about this.

[lahma]

LGTM, tested migrating Jint and changes were straightforward. Tests green on that side too.

[adams85]

@lahma Thanks for checking the PR out and verifying it in Jint! 👍

I'd probably release this along with #381 once time is ripe for merging that. But please do as you see fit.