Re-think CSTVisitor APIs

[bd82]

• Cab the CSTVisitor avoid coupling to the Parser instance?
• Can the default traversal be implemented as a fallback behavior instead of actual prototype methods?
• Can the CST Visitor related validations be implemented as external utilities rather than methods?
• Can we separate the validations of "all visit methods implemented" and "redundant visit methods found"?
• Any additional CST related utilities that should be provided?
• The CSTNode being visited is not accessible in each specific visit method

[bd82]

More feedback from @matthew-dean

For visitor methods (https://sap.github.io/chevrotain/docs/tutorial/step3a_adding_actions_visitor.html#introduction), I would have expected that this.visit, if visiting an array, would return an array of visit results. However, that does not appear to be the case. I think this is one of those cases where there is non-intuitive behavior based on the structure of the CST. That is, the CST always produces children as arrays, for whatever reason, even if they only have one production. So maybe the typical scenario is that you would only visit arrays with a length of 1?

...Okay, just found the doc note: "If an array is passed (ctx.fromClause is an array) it is equivalent to passing the first element of that array"... IMO that should be called out in a dedicated section on arrays, with a convenience method such as visitArray to return an array of results.

[bd82]

Can we separate the validations of "all visit methods implemented" and "redundant visit methods found"?

Redundant visit methods validation was removed in #1847