Use `Import-Package` instead of `Require-Bundle` for org.eclipse.core.runtime.

This should allow Luna installs without conflicts due to “double vision” of
the `javax.bind.ws` package. This workaround was suggested in this Eclipse ticket.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=430458
Merge pull request #751 from dragos/issue/resolution-order-luna

Use `Import-Package` instead of `Require-Bundle` for org.eclipse.core.runtime
Treat projects in subfolders correctly in `NewFileWizard`

Normally a project is located in the root of the workspace, which would
lead to a physical location like '/workspace/project/file'. But it is
totally valid to have a file in a physical location like
'/worskpace/subfolder/project/file'. It is even possible to have source
folders that are linked resources and can therefore be located anywhere
on the file system. In these cases the wizard did not work correctly.

Internally the wizard was based on `IPath` types which was a problem
because they couldn't handle linked resources perfectly well. In case a
linked source folder points to another folder in the workspace, an
`IPath` object did always point to the real file on the file system. If
the path would have pointed to the symlink there would have been no way
to determine its real location.

To overcome this limitation the `IPath` references were replaced by
`IFile`, which abstracts over workspace files and therefore can
correctly recognize symlinks.

Fixes #1002185
Select project explorer element after wizard created new file

Fixes #1002188
Apply reviewer comments

- NewFileWizard.pathOfCreatedFile is renamed to
  NewFileWizard.createdFile
- FileCreator.createFilePath is renamed to FileCreator.create
- FileUitls.createFile uses IResource API instead of Java file API
Merge pull request #748 from sschaef/t1002185-subfolder-support-for-wizards

Treat projects in subfolders correctly in `NewFileWizard`
Don’t lose warnings when building incrementally.

The builder clears all problem markers in a  given project, but not
all warnings will be reported in an incremental compiler run. For example,
the change might not require recompilation of a file that contains deprecation
warnings. In this case we’ll add markers based on the Analysis object supplied by Sbt.


See https://github.com/sbt/sbt/issues/1372

Fixed #1002148
Cleaned up EclipseSbtBuildManager.

* removed the indirection from SbtReporter to BuildReporter, which was a
  leftover from the refined build manager. No need to route through a compiler-based
  reporter anymore (and mapping back and forth between positions and severities)
* reorganized the file to start with fields and public methods
* moved all file operations to use IFile instead of compiler-based AbstractFile
Remove the build manager choice, since the refined build manager is long gone.
Additional test for builder, making sure we leave no stray error markers after undo.
Reinstate length for build error markers.

The Scala compiler uses offset positions, so errors are reported at
the starting position. We derive a length based on the identifier
at the given position, so that error markers have a non-zero length,
and look better in the UI.
Report remaining work based on the current and total work units.

The previous code was the original one, with no justification for
using `lastTotal` instead of the actual current work unit. Changed to
what seems more logical.
Keep track of what files have been compiled

The previous heuristic that a file with error markers means it was compiled
didn’t work very well. We could have a file that has no error markers but
it *was* compiled, in which case we’d add outdated error or warning markers.
Merge pull request #754 from dragos/issue/deprecation-warnings

Sbt builder fix and refactor
Add functionality to auto enable new wizard elements

Fixes #1002191
Trigger auto activation of new wizard entries only once
Add constants for Scala file creators to `ScalaPlugin`
Apply reviewer comments

- Move `RichWorkbench` to `EclipseUtils`
- Remove early info logging, because it is not very useful and maybe
  even problematic due to possible deadlocks with stdout redirecting