Add static private class field support

[jridgewell]

Q	A
Bug fix?	no
Breaking change?	no
New feature?	yes
Deprecations?	no
Spec compliancy?	yes
Tests added/pass?	yes
Fixed tickets
License	MIT

Private class fields can be static (according to the unified proposal).

[xtuc]

Nice job @jridgewell.

Do you think we could merge classProperties and classPrivateProperties plugins in Babylon? Since it just adds the static syntax.

[jridgewell]

I'll do that in a second PR.

[diervo]

@xtuc @jridgewell
We should wait for merging both plugins until publicFields get to Stage3, which hopefully will happen in the next TC39 meeting (in about a month).

There is still some debate on the committee on wether this.#x will be required and so let's wait for the final version.

Decorators might be another moving piece that is very intertwined, but I guess semantics are kind of stable? so its mostly implementation details from a babylon point of view.

Lastly, just an FYI I think @littledan wants to present private methods, so let's see which Stage that lands... :)

[littledan]

Have comma-separated field declarations landed yet? If so, it'd be nice to have tests that demonstrate that you can mix static public and private field declarations in a comma-separated list.

[diervo]

PR is pending to be merged: #608

[littledan]

This looks great. I don't see why it should wait until Stage 3 to land--I presented static private fields to the committee in the May meeting with this syntax and didn't hear any concerns. I think @hzoo is doing a lot of work to communicate to users that Stage 2 proposals are unstable.

For decorators, we unfortunately don't have spec text yet which combines it with fields; hope to fix that soon. Private methods haven't been presented yet, so I guess they will wait a bit longer to add to Babel.

[diervo]

@littledan I was not talking about this PR, this is good to go, the refactor to combine public/private fields is what Im saying to postpone til we figure out the this.#x syntax.