BaseNode.equals support, and other ast goodness from python-fluent

[Pike]

This is basically a port of
https://github.com/projectfluent/python-fluent/blob/90301381e9b4d56b317bd6f15adf38936569f023/fluent/syntax/ast.py#L76-L120

Creating a PR early on to ensure that node 6 and 8 pass on the js features. For example, the use of Object.keys, which is rumored to be OK per http://node.green/#ES2015-misc-Object-static-methods-accept-primitives-Object-keys.

[Pike]

stas, I think this is ready for review.

I gave all those things from python-fluent a go (w/out traverse).

Tests are heavily inspired by the python tests, too.

Questions I know of: ignoreFields vs ignore_fields. And is Object.create the right way to instantiate a new object of the same type, given that the kwargs trick in python doesn't work in js? (I don't think it does).

[stasm]

Nice work! I'll finish the review tomorrow. For now, I'm leaving a few comments for your consideration.

[stasm]

Let's add a test which verifies that the original nodes have their variants in unchanged order after these tests run, please.

[Pike]

I'm dropping the ordering completely, per comment above, and update the tests accordingly. Let me know if there's more to do here.

[Pike]

There's still an open question I have on sortingKey. It's really useful in tooling as a canonical representation of a VariantKey, in compare-locales, and also in Pontoon for example.

[stasm]

Thanks for addressing my comments, @Pike! This looks good to land.

Regarding the question about sortingKey: serializedKey which we discussed last night would work for me. I think a helpful excerise is to imagine what this field would be for variants with StringLiterals as keys (projectfluent/fluent#90). Would we want to serialize them wrapped in double quotes, to differentiate them from keys which are Identifiers? Or should [foo] and ["foo"] serialize to the same thing?

I'm a bit concerned that having this field is mixing concerns. The use-cases present in Pontoon should really just use FluentSerializer or a custom serialization layer. The use-case of finding duplicate variants could also be solved with a one-line function in compare-locales. But, since this is an extra API of python-fluent's AST rather than part of the reference AST, I see the tooling value here and I don't want to block.

[Pike]

I've taking your comments and mulled over them, and then ended up removing the sorting_key in python. I replaced the use in compare-locales in https://phabricator.services.mozilla.com/D23813, which had a couple of arguments to change the way that code worked to begin with. For variant keys, I went for serialization. For attributes, I just hard-coded the AST structure accessor.