Switch to cross-compiled versions of Scala modules.

For the moment, only `scala-xml` is cross compiled.
Merge pull request #497 from dragos/fix/cross-compiled-modules-211

Switch to cross-compiled versions of Scala modules.
Added a ``FlakyTest.retry`` combinator to be re-run tests known to be flacky

In our test suite we have a number of tests that are known to be flacky. The
``FlakyTest.retry`` combinator re-executes the same time up to N times (where
N is defaulted to 5 at the moment).

While we should of course strive to fix all sources of flackiness in tests, this
is a pragmatic solution to prevent spurious build failures.
Highlights Scaladoc macros that are wrapped in braces

The new rule needs to be placed in front of the normal macro rule
because it starts with the same identifier but contains more
characters to detect. Thus it needs to be detected first.

Fixes #1001836
Remove unnecessary trys
Switched to the new groupID for scala-xml.
Switched to cross-compiled scala-parser-combinators.
Merge pull request #500 from sschaef/t-clean-up-try

Remove unnecessary trys
Added Maven profile ``retryFlakyTests`` to reduce spurious test failures

Use the Maven profile ``retryFlakyTests`` for being robust against tests that
are known to be flaky. Inside Eclipse, you can achieve the same by passing the
system property ``-DretryFlakyTests=true``.

This profile should only be used by the Scala/IDE integration script to avoid
failing because of flakiness in our regression suite.
Merge pull request #498 from dotta/transient/dont-run-flaky-test-in-test-suite

Added additional Maven profile for skipping known flaky tests
Merge pull request #499 from sschaef/t1001836-scaladoc-macro-braces

Highlights Scaladoc macros that are wrapped in braces
Merge pull request #502 from dragos/fix/cross-compiled-modules-211

Fix/cross compiled modules 211
Made `ScalaSourceFile.createFromPath` implementation thread-safe

The former implementation of `ScalaSourceFile.createFromPath` was not
thread-safe, which was problematic because the method is called concurrently
from different threads. The actual reason for the race-condition is that
`HandleFactory` is not thread-safe. (Side note, this is why  I was keeping
getting "Resource XXX does not exist." exceptions while reviewing scala-search
PR #68).

The fix consists in making sure that no `HandleFactory` instance is shared
across threds. One relevant point is that `HandleFactory` performs caching for
speeding up retrieving an `Openable` from a `path` (the caching is the actual
reason why the class isn't thread-safe). This is an important aspect to keep in
mind, and which should motivate the implemented fix.

I could see two possible ways to fix `ScalaSourceFile.createFromPath`:

1) Create a fresh instance each time (and also provide an additional method to
allow callers to explictly pass  a `HandleFactory` when they know the instance
isn't shared among threads).

2) Delegate the responsability of never sharing `HandleFactory` instances among
threads to a `ThreadLocal`.

Option 2) seemed to be the best fix, because

* correctness is ensured by design,
* no changes are required from the caller, and
* it maximize opportunities for re-using the cache maintained by `HandleFactory`.

Last but not least, I've taken the liberty of breaking both source and binary
compatibility. I believe the `handleFactory` instance was public for historical
reasons, and I don't expect anyone to complain about this breakage. However, I
could also re-introduce it, making it a `def`, mark it @deprecated, and simply
return a fresh `HandleFactory` instance.

Fixes #1001846
Merge pull request #505 from dotta/issue/fix-race-condition-happening-when-source-is-created-1001846-bis

Made `ScalaSourceFile.createFromPath` implementation thread-safe
remove controversial & undocumented deprecation
Fix typo: s/maven-bunble/maven-bundle/
Upgrade to scala-maven-plugin 3.1.5
Upgrade to scala-xml v1.0-RC3
Overrides Java launch method to find existing Scala launches

Since Eclipes 3.8, a package private method is used by JavaLaunchShortcut
to find existing launch configurations for a given type.
Overrides the Java launch method to use different logic to find the Scala
launch configuraitons.

Fixes #1001447
Add Apply case to ScalaCompletions. Fixes #1001218

This allows scalaCompletions to handle method invocation completions.
Also refactored scalaCompletions to tidy things a little.