Clean file handle on refreshing changed files

The custom code I wrote to read an IFile was not releasing the file
handle correctly.
It was eventually closed when the object was GCed.
Replaced the code with some internal jdt util method.
Removed the incorrect method

Fix #1000909
Handle invalid target packages in the Move participant.

When the target package of a move refactoring cannot be found (e.g. because
the target is not a source folder), we abort with a warning. The user can
then still move the file, but he will be warned that the source won't be
changed. The JDT doesn't warn the user but simply moves the file without
refactorings its content.
Better matching between file-system paths and workspace resources.

A file-system path may correspond to several resources in the workspace. We used to choose
the first one, which lead to build errors being attached to the top-level project in nested
project setups, even when the error belonged to a nested project.

Fixes #1000734, #1000621, #1000881. Should be back ported to 2.0.x
Formatting changes.
No need to call setIsStructureKnown, as it is already done by the caller

In ``ScalaCompilationUnit#buildStructure``, there is no need to call
``setIsStructureKnown`` on the current compilation unit, as it's the
caller's responsability to do so.
``ScalaSelectionEngine`` uses now a ``ScalaCompilationUnit`` (instead of a
``ICompilationUnit``)

Both ``ScalaSelectionEngine`` constructor and the ``select`` method started
with casting the passed compilation unit to ``ScalaCompilationUnit``.  Beside
not being type safe, this unsafe cast is not needed, since clients of
``ScalaSelectionEngine`` can already pass a ``ScalaCompilationUnit``.
Better implementation of ``ScalaProject.sourceFolders``
Refactoring in test plugin

Removed ``ScalaUnit`` type alias and replaced usage of ``ScalaUnit`` with ``ScalaSourceFile``.
created test infrastructure
find ref test prototyped
Need a good commit message
Find Method references should not return the declaration of the (re-)searched
method

When looking for references of method `xxx`, the method itself should not be
reported as a match. Indeed, find references is about finding usages of `xxx`,
not the declaration (and that is why a find declaration action exist).
No more "operation unavailable" popup on find references action

When Find References was performed on a val/var declaration, a popup dialog
used to be shown saying:

> The operation is unavailable on the current selection. Please select a valid
> Java element name.

The issue is in the compiler symbol found for the val/var declaration.
Apparently, the symbol's name can contain a trailing space (why??), which
caused the equality test between the editor's current selection and the
symbol's name to always fail.

The trivial fix is to trim the symbol's name.

A test was also created to prove the issue is now corrected.

Test #1000773
Tested find references for both class' constructor and class's type

Created tests to check that:

* class' constructor references are correctly reported.
* class' type references are correctly reported (also for type bounds).

Fix #1000063
I'm not sure this commit is actually meaningful
Tested find references for companion object members.
stashed: all tests pass
Added FindReferenceTests to regression suite