Clean up duplicate classes migrated into jdt.core.manipulation

[rgrunber]

@testforstephen , I think you migrated a lot of these in org.eclipse.jdt.ui to org.eclipse.jdt.core.manipulation.

Let me know if we can go ahead with this cleanup.
Note : As mentioned in #1911 (comment), I adjusted 5 test asertions upon updating the target platform.

To quicky find possible candidates :

cd ~/git/eclipse.jdt.ui/org.eclipse.jdt.core.manipulation
for f in `find -name "*.java" -printf "%f\n"`; do find ~/git/eclipse.jdt.ls -name ${f}; done;

To compare the differences, I used something like :

for f in CodeScopeBuilder.java DimensionRewrite.java JdtASTMatcher.java LocalVariableIndex.java ModifierRewrite.java ReplaceRewrite.java StatementRewrite.java TypeAnnotationRewrite.java TypeBindingVisitor.java VariableDeclarationRewrite.java;
  do diff -uwB `find git/eclipse.jdt.ls -name $f` "`find git/eclipse.jdt.ui -name $f`"
done

[fbricon]

That's the kind of PR I like ;-)

[testforstephen]

LGTM.

[rgrunber]

This small mistake introduced a regression. Thanks to @fbricon for catching this. Currently creating compilation units (classes/interfaces/enums) from unresolved symbols fails to create the file. You can see the missing

"options": {
"overwrite": false,
"ignoreIfExists": true
},
"kind": "create"

when comparing the data.

When I planned this refactoring, I wanted to use CreateFileChange from org.eclipse.jdt.core.manipulation/core extension/org/eclipse/jdt/internal/corext/refactoring/nls/changes/CreateFileChange.java and remove our copy. However, I noticed a key difference. Our copy opened up getPath() whereas it's restricted in the upstream version.

-   protected IPath getPath() {
+   public IPath getPath() {
        return fPath;
    }

Rather than wait for upstream to adopt it, I decided to just undo the change and continue using our copy of CreateFileChange. I must have left this import in, and because it resolves, I never saw any indication of a problem.

The result is that we use org.eclipse.jdt.internal.corext.refactoring.nls.changes.CreateFileChange when creating the file change, but our ChangeUtil code does an instance of check on our org.eclipse.jdt.ls.core.internal.corext.refactoring.nls.changes.CreateFileChange so we fail to correctly recognize this case.

Just changing this line fixes things, so I'll post a change, and hopefully there's a way to test this.