Enhance AstDumper for debugging and testing

[niloc132]

Enhances the AstDumper utility class with the aim of bringing back some of the functionality previously removed in 64f9b00, where individual methods could be traced from source Java all the way to JS output. This is a small step in that direction that nevertheless provides more insight into what the compiler is doing, through a series of changes:

• Improve printed Java output - classes should list their name, enums and records should be labeled as such, etc. AST traversal is made more visitor-like to make filtering easier.
• JS AST should also be printed, rather than ending with the Java optimization loops, allowing insight into JS passes.
• A filter can be applied to the ast at any stage, resulting in only printing code from the specified files or lines, to more easily follow specific changes through a program.

More improvement remains - multiple permutations may end up mixed in the same file, different compiler passes are not individually listed or labeled, arguments are re-parsed every time they are used, but impact to the API is minimal for now.

[niloc132]

Example of generating an AST dump with JS output included, while working on a fix for #9731 - running a build of the Hello sample before and after the change, and running diff -U10 before.dump after.dump results in this sample output (demonstrating two ways that the code is improving):

 function Button(handler){
   $clinit_FocusWidget();
   ButtonBase.call(this, $createPushButtonElement($doc));
   ($clinit_DOM() , this.element).className = 'gwt-Button' || '';
-  ($clinit_DOM() , this.element).innerHTML = 'Click me' || '';
-  $addDomHandler(this, handler, ($clinit_ClickEvent() , $clinit_ClickEvent() , TYPE));
+  this.element.innerHTML = 'Click me' || '';
+  $addDomHandler(this, handler, ($clinit_ClickEvent() , TYPE));
 }

[niloc132]

CompilerTest doesn't fail locally, investigating...

[niloc132]

Failures appear to be an example of #9947, rerunning.

[zbynek]

This makes suppressType unread.

[niloc132]

You're right... makes me suspicious that I "broke" this, at least in the context of for loops. I wish this had tests (since apparently it once upon a time produced compilable code, but that was many years ago), but I don't think it is critical to add them just for a debugging tool just yet...

I'll verify what our behavior is now here. My hunch is that it doesn't matter, and that we have just an assignment JBinaryExpression instead, but we'll see.

[zbynek]

I don't know what was the intention behind this flag and if it's still relevant (and if it is needed for for loops, is it also needed for try-with-resources?), but since this is just for debugging it should be fine to remove the flag.

[niloc132]

Suggested change