Small improvement in ``CompletionTests`` test runner

If the test does not contain at least one occurrence of the expected marker,
fail the test.
Fixes test about ranking of completion proposals

For this to work we need to sort (in decreasing order) the completion proposals
returned by the ``ScalaCompletions.findCompletions`` methods. This needs to be
done only during testing because the JDT Completion Proposal component already
does it for us.

Interestingly, I believe this test was actually never run because of the bug in
the CompletionTest runner that I fixed in my previous commit (SHA:
48253e8de4daab7f5288030a8628d5053937c6ee).
Do not lock the whole workspace when running the ``ProjectsCleanJob``

I noticed that the default implementation of
``ResourcesPlugin.getWorkspace().getRuleFactory().buildRule()`` returns a
scheduling rule that **locks the whole workspace**. That seems unnecessary,
hence I've changed the implementation of the ``ProjectsCleanJob`` to only lock
the projects that are about to be cleaned.
Merge pull request #355 from dotta/feature/improved-completion-test

Small improvement in ``CompletionTests`` test runner
Fixed PC race condition in semantic highlighting

I see no reason for treating Tuple/Function in ``AppliedTypeTree`` nodes any
different that any other type application. Furthermore, if you look at the two
``case AppliedTypeTree``, it looks like we don't really need the information.
All we need is **not traversing** the ``Select`` of the ``AppliedTypeTree`` if
it doesn't appear in the source code (i.e., it doesn't have a range position),
which is what I do with this commit.

Fixes #1001623
Merge pull request #358 from dotta/issue/race-condition-pc-1001623

Fixed PC race condition in semantic highlighting
Merge pull request #361 from dotta/issue/project-clean-job-should-not-lock-workspace

Do not lock the whole workspace when running the ``ProjectsCleanJob``
enable scala actions on Java projects in non-Java perspective
(cherry picked from commit 82e6b26a7262da7bc3eed045d96377740ab4942d)
Fix rename refactoring selection/tab behavior

When entering rename refactor mode,
 - the selection should not be disturbed
 - tabbing should cycle through all instances of the symbol being refactored

This is the behavior of the JDT rename refactoring.

Fix #1001641
Merge pull request #362 from skyluc/issue/java-project-actions-1001597

Put changes from pr #357 in the right branch
Name the "selectFirst" argument when invoking enterLinkedModeUi
Merge pull request #363 from pelotom/rename-refactoring-fixes-1001641

Fix rename refactoring selection/tab behavior