Fixed ECMAScript private member highlighting

[lizclipse]

It's bugged me that private members haven't been highlighted in editor I've used so far, so I've added the queries to allow actually restyling. Currently, they're targeted as a .private child under variable.other.member and function.method so that they automatically take on the existing highlighting properly while being individually style-able. This was a personal preference, since it would match other langs which don't colour public & private methods/field differently while allowing the unique syntax of JS to be taken advantage of, however there's 2 other options that could also work:

• Remove all the .private parts and match other langs exactly
• Rename to not be a child and instead standalone (eg variable.other.private-member) to preserve the current lack of styling

Example code that shows what syntax it now highlights:

export class Test {
  regularField: string = "working highlights";

  #privateField: string = "fixed with these changes";
}

Funnily enough, even GitHub doesn't handle private props properly. Not sure if that's an oversight or a stylistic choice, but it bugs the hell out of me.

[lizclipse]

I have no idea what that test failure is about. Running it on my own mac I can't repro it and it's complaining about the Rust grammar, which I haven't touched.

[archseer]

Github CI switched their macOS runners to ARM. We cleared the cache yesterday so the tests should pass now

[the-mikedavis]

Could you add the new keys to the docs? https://github.com/helix-editor/helix/blob/master/book/src/themes.md#syntax-highlighting

[cotneit]

I would drop .private, adding new keys feels unnecessary here

[lizclipse]

@the-mikedavis Done

@cotneit I've made them child keys so that they can just be ignored, but my preference is to keep them because it allows colouring the private fields/methods slightly differently if you wish - eg in my custom theme I have private members the same colours with the saturation turned down a bit to make them distinct.