refactor: leverage Prettier's AstPath and comment attachment

[jtkiesel]

What changed with this PR:

The printer is totally refactored to leverage Prettier's own AstPath and comment attachment to reduce the amount of work done by our own code (including a reduction of >1300 lines of code). Also improved type safety a bit, specifically by making CstElement a union type of IToken and all possible CstNode types, and in general aligned formatting a bit closer to Prettier's own formatting for JavaScript/TypeScript (one of those happens to be #720).

Because I wanted to prove that it would be easy to resolve issues with comments after refactoring to use Prettier's built-in comment attachment, I also integrated the implementation for #534, while fixing the comment issues I was having in #716.

Because this PR directly leverages Prettier's printing library, there are a few other issues that I have not yet verified, but may be able to be closed with the merge of this PR, including #487 and #660.

Because I renamed some files from *.js to *.ts, the full diff of the commits in this PR makes it appear as though the *.js files were deleted, but I renamed them in the 1st commit to preserve their git history. Because of this, we should avoid squashing this PR's commits when merging, if we want to keep that history.

Something to consider: I removed the java-parser package's custom comment attachment capability, and instead simply attach all comments to the comments field of the root node, which is what Prettier expects to allow it to move the comments to the appropriate nodes itself. This would be considered a breaking change to the java-parser package, and so should probably result in a major version increment, if we were to keep this change (though I don't really know how we've been treating breaking changes to the parser in the past). If instead, we determine that we wish to continue supporting our own custom comment attachment in the parser itself, then we could bring it back, and simply make it configurable to disable it. I'm open to either approach, but would obviously prefer to gut the code and reduce our maintenance burden if we can.

Example

Options

--experimental-operator-position start

Input

class Example {

  void example() {
    var rotateX =
      (RANGE / rect.height) * refY -
      (RANGE / 2) * getXMultiplication(rect.width);
  }

  void nestedForStatement() {
    for (SomeClass<?> elem : elements) for (SomeClass<
      ?
    > elem : elements) for (SomeClass<?> elem : elements) doSomeThing();
  }
}

Output

class Example {

  void operatorPositionStart() {
    var rotateX =
      (RANGE / rect.height) * refY
      - (RANGE / 2) * getXMultiplication(rect.width);
  }

  void nestedForStatement() {
    for (SomeClass<?> elem : elements)
      for (SomeClass<?> elem : elements)
        for (SomeClass<?> elem : elements) doSomeThing();
  }
}

Relative issues or prs:

Closes #534
Closes #592
Closes #720
Obsoletes #595
Obsoletes #716
Obsoletes #719