Move the relocation code from the factory to the ClassFileEditor

[laeubi]

Currently the ClassFileEditorInputFactory performs some action to relocate ordinary class files into proper types of the project.

This has some problems:

• recovery should ideally be very fast because this code is called very early even before the UI is visible
• as it is not supported to return null error handling is not reliable possible any error will be swallowed and results in a generic error message that is hard to understand by the user and hard to track down because there is no stacktrace to the original code

This now do the following:

• create a new carrier input HandleEditorInput that is just a wrapper around a string and except for the case the memento itself is invalid we can always return a non-null value
• the existing ClassFileEditor#transformEditorInput method is enhanced to contain the code previously at the factory

This has the advantage that now we can throw CoreEceptions in case anything goes wrong. Also the code is now part of the editor itself so any advanced handling (e.g. delayed loading in a Job, other cases of transformation needed) can now be handled not only in the editor but with full access to the editor instance itself.

@iloveeclipse this does not change any behavior (by intention), it only moves the code from the factory to the editor, so whatever changes one want to make to the editor in the future it is now completely possible in the the editor and shows a stacktrace where the problem occurs (so no swallow of exceptions):

Before

Without this only the generic error part is shown without a usable stacktrace pointing to the location where the problem occurs, restarting Eclipse again and the Editor is lost entirely.

After

It now shows still an error but now with a usable stacktrace, after a restart it retains the editor

[laeubi]

If I now combine this PR with

• If there is no source show the raw class file content #2357

and the approach of @merks that was applied to the JavaEditor

• Wait for deferred PDE classpath initializer before initial reconcile #2374

one can probably do this (only a rough proof of concept!):

• Restore the type from class file input in the background #2380

what has the advantage that the editor recovers faster (as the call to element.exists seem to be possibly slow as well as searching the type) and can sit waiting until everything settles without blocking the UI

[merks]

This looks like a refactored improvement over the current worse behavior. I assume this is a small step toward a full solution where this step deals only with the case that currently is an abject failure with poor feedback and a non-restorable editor.

At first I was concerned that it would always change the editor input even when there is no problem but I see that the new input class is "unwrapped" so when there is no problem the input is the same as before.

So it looks fine to me.

[iloveeclipse]

I will push a PR in a second that addreses all points.