Rework changes in processing.mode.java to realign with previous features/clear up current behavior

[processing-bot]

Created by: benfry

The changes to break out getCoreImports() and others will likely have trashed Android Mode pretty badly; as these were public methods that are overridden by subclasses like Android Mode. That's why they weren't static in the first place, and they were given a single point where they could be overridden.

[processing-bot]

Created by: benfry

This was originally titled “untangle ImportUtil inside processing.mode.java.preproc.code” but I think we might need a broader rethinking of the changes inside processing.mode.java in general. We may want to re-apply the changes piecemeal so that there's a better sense of where everything has moved.

[processing-bot]

Created by: benfry

With #70 I've started to move things around a bit inside Java Mode. So far:

• I've gotten rid of the pdex package, since it wasn't actually a useful distinction, because it was entangled with everything else.
• I've moved more of debugging into the .debug package
• I've merged and broken out a few classes where possible.

The main package is now enormous, and needs to be cleaned up further. Thinking out loud, the general direction for additional changes I plan to make here:

• processing.mode.java should contain the portions that talk to integrate into the PDE, i.e. this can contain Swing/AWT code as needed. Same for debug, since that's only to be used by the PDE. Not going with the .ui suffix here since that would require changing a lot more of the behavior of the PDE. And while it might be better design, it's a lot of work for essentially zero benefit.
• processing.mode.java.preproc should contain everything we need to preprocess code, perhaps including the service that does the background updates, though since that's more frontend related, that might live in the root. .pde files go in, .java files come out, ready to be compiled.
• processing.mode.java.preproc.issue looks like a maze at the moment… I'm concerned this has a lot of levels of abstraction that aren't really helping us.
• processing.mode.java.runner should be doing all the work of running a live sketch. Ideally it wouldn't have AWT connections, but I'm not terribly interested in being strict here, since running a sketch (even from the command line) broadly means we're in a windowed environment.
• We probably need a processing.mode.java.build package as a way to break out any of the build-related things from processing.mode.java, i.e. calling the compiler, Export to Application, etc. This would also be something accessible to the command line tool as well.

[processing-bot]

Created by: benfry

The reason for this shift was also based on an experiment with switching to RSyntaxArea instead of JEditTextArea, which revealed a lot of the difficulties in how JavaEditor and others are tangled up with one another.