import regions not computed for .class files

[fbricon]

When opening a .class file, the import statements are not folded by default, with "editor.foldingImportsByDefault": true. Seems you can't even fold the import block manually. Something's fishy here.
I noticed that in #2132 (comment)

[rgrunber]

I just noticed the same behaviour in Eclipse as well for classfiles. Looking at the code, it seems like we check for the IImportContainer child element of an ICompilationUnit to get the folding range. However, the IClassfile doesn't seem to have such a child element.

[rgrunber]

Explanation : https://bugs.eclipse.org/bugs/show_bug.cgi?id=72503, https://bugs.eclipse.org/bugs/show_bug.cgi?id=42097

[rgrunber]

Just a note, this is still possible to implement. Just not from the Java model side. On the AST side, we could find the node corresponding the import statements, and use those offsets to generate the folding range. I would just be curious if the Java model side has anything at all to accomplish this.

Update : a classfile shouldn't have an AST, but if we have the sources for the classfile, I don't see why we couldn't just generate one and go by the offsets. Hacky, but if we really wanted this, it could work. Alternatively we could investigate more upstream.

[baincd]

As a workaround, I have created a VS Code extension that adds a folding region for imports on .class files: https://marketplace.visualstudio.com/items?itemName=baincd.java-class-imports-folding

[rgrunber]

Instead of using the AST parsing facility, @JessicaJHee went with using the scanner's ITerminalSymbols.TokenNameimport to detect the import range. We do use the scanner for other parts of the folding range computations. This should work as expected now.