Test demonstrating wrong hyperlinking on metod w/ default arg

This test demonstrates that the Tree returned by `askTypeAt` is wrong when the
request is executed *after* fully-typechecking the sources used for the test.

I've debugged the problem inside the Scala IDE, and the reason why this happen
is that `askTypeAt` returns the enclosing `foo` DefDef method symbol, instead
of the expected Select `Bar.bar` node. The enclosing method is returned becuase
all Trees inside the method block have a *TransparentPosition*, all the way
down. The impelmentation of `askTypeAt` relies on
`RangePositions.Locator.traverse` to return the deepest, non-transparent, tree
that includes the passed position. And, because all positions are transparent
inside the `foo` method's body, then the `foo` symbol is returned.

An additional interesting fact is that it looks like one of the transformation
happening during typechecking is to blame for updating the Tree with the wrong
kind of positions. In fact, if the source file isn't typechecked, the correct
symbol is returned.

Enable the test once https://issues.scala-lang.org/browse/SI-7915 is fixed

Re #1001921
`retryFlakyTest` now enabled by default

As the last failures of the PR job validator demonstrate, it's quite easy to
get several flaky builds in a row. This is painful to a degree that cannot be
tolerated anymore, which is why I'm enabling the `retryFlakyTest` flag by
default, and you should explicitly pass `-DretryFlakyTests=false` to the build
if you don't want known flaky test to be re-run.

By the way, I'm not removing the `retryFlakyTests` profile because the scala
validation script uses it, and this way we can easily change again the default
of `retryFlakyTest` without having to go and update the validation script.
Merge pull request #570 from dotta/wip/enable-retry-flaky-test

`retryFlakyTest` now enabled by default
`ScalaPresentationCompilerProxy.apply` should never return `Some(null)`

The former implementation of `ScalaPresentationCompilerProxy.apply` could
return `Some(null)` if the passed `op` returned `null`. This was not the
intended semantic.

A different issue I'm thinking about is how I can provide an overload of
`ScalaPresentationCompiler.apply` to allow to pass either an `op` of type
`ScalaPresentationCompiler => U` or `ScalaPresentationCompiler => Option[U]`.
The simplest way to do so would be to have two different methods, but I want to
think about this a bit more (in fact, I'm still not convinced we shouldn't
simply keep the current implementation).
Merge pull request #569 from dotta/issue/wrong-hyperlinking-1001921

Test demonstrating wrong hyperlinking on metod w/ default arg
Merge pull request #571 from dotta/issue/do-not-return-some-of-null

`ScalaPresentationCompilerProxy.apply` should never return `Some(null)`
Removed whitespaces from test sources to make Scalastyle happy
Splitted side-effecting logic from pure computation in `ScalaCompletions`

Created two nested method `typeCompletionsAt` and `scopeCompletionsAt` to
clearly separate the side-effecting logic from the pure computation in
`ScalaCompletions`.
Don't add parameter list on import completion for module's methods

Also, added ignored test for Re #1001919

Fixes #1001125
Added explicit 'override' in `ScalaCompletions`
Merge pull request #568 from dotta/issue/import-completion-for-module-methods

Issue/import completion for module methods
Merge pull request #573 from dotta/transient/remove-scalastyle-warnings

Removed whitespaces from test sources to make Scalastyle happy
Use plain Scala OSGi bundles to build the IDE.

* toolchain is used only to build sbt
* all Scala-related dependencies are resolved through Maven
* bundles not needed for execution (scala-swing, continuations, various source attachments) are added to sdt.core
* features need an extra step, because in 2.11 we need to ship two extra bundles (xml and parser combinators). This is done through the new -Pset-features profile in build-all.sh

As a bonus, all Scala bundles have correct source attachments now, so plugin
development should be much easier.

Fixed #1001889.
Reviewer comments:

- added Scala compiler sources
- added xml and combinator versions only in the 2.11 profile
- removed useless dependency on HasLogger
- removed exported dependencies from sdt.core project files
- removed superfluous version numbers in dependencies
- fixed runtime library for build-tools to always be 2.10
Removed old and no longer used CHANGELOG file
Merge pull request #576 from dotta/transient/remove-changelog

Removed old and no longer used CHANGELOG file
`ScalaClassFileEditor` should always hold a `ScalaClassFile`

There doesn't seem to be a good reason for not creating a `ScalaClassFile` when
source attachments cannot be located.

Doing so has two nice consequences:

1) When sources are manually attached to a Scala JAR, and a classfile is opened
   in an editor, the source is now correctly syntactically highlighted. This
   basically fix half of ticket Re #1001926 (the other half is triggering
   semantic highlighting).

2) `ScalaClassFileEditor` instances are now ensured to be always created with
   an underlying `ScalaClassFile`. This is an important fact, as
   `ScalaClassFileEditor` assumes it (in fact, the `ClassCastException`
   reported in ticket Re #1001925 was happening because this implicit contract
   was broken, i.e., it was possible that a `ScalaClassFileEditor` could be
   created with a (Java) `ClassFile` when no source attachment was found.

By the way, the `ClassCastException` issue mentioned in point 2) could be
reproduced by copying a **Scala** classfile in the root of a project, and then
trying to opening (by double-clicking on it from the Package Explorer view)
would result in an error prompted to the user.

Fixes #1001925
Merge pull request #575 from dotta/issue/semantic-highlight-class-cast-exception-1001925-bis

`ScalaClassFileEditor` should always hold a `ScalaClassFile`
Merge pull request #565 from dragos/improvement/scala-osgi

Switch to vanilla Scala OSGi bundles
'Add explicit type' quick assist.