Better editing support for groovy files that are not on the build path

I have been playing around with this in my local workspace and this is working quite well. By simply removing the guards on GroovyCompilationUnit.buildStructure and elsewhere, I now have navigation, content assist, type inferencing, and mark occurrences working. The caveats are that files outside of the build path cannot be referenced by any other files, search doesn't work inside of these files, and refactoring does not work. These are restrictions that is similar to those for Java files in JDT.

So as we discussed, we can choose to not be eclipsey in terms of the extra lookups. Both the ability to use ast transforms that are part of the project and grab support use a classloader to make types available that are not on the classpath. The classpath to be used could be communicated in a similar way in which we currently communicate that the file is a script (see GCUD.tagAsScript() and how that filters through to GCUScope). I think this is worth continuing with once we have a real use case and the gradle support is able to conjure up the classpath to use. I'll check with Kris next week about whether the API can provide it. Where we will have to be careful is that using a classloader kind of just gives us augmentation of the classpath, we'll need to also affect the JDT resolver and prevent it finding things in these situations (if we truly want to use an entirely different classpath for the scripts).

Now the script support seems to be behaving, perhaps we also need to make the change that will mean the scripts are not passed to the compiler (for a proper build), even if in a source folder (if they match the script patterns). ie. remove our old hacky way of supporting scripts.

I am resolving this issue as fixed since the main part of this is done. Now, editing groovy files outside the build path is supported much more deeply. It is an entirely different problem to enhance the classpath for reconciling of these files.