Bumps version numbers
Increase test timeouts (possible source of flaky classpth tests).
Create features for each Scala versions

This will allow to install multiple versions of Scala on
the same Eclipse installation.
The main sdt build phase now only depends on p2 repos, external or local
created in the previous phases.
Some version definition
Tweaks the arguments in the build script
Creates a Scala 210 jars bundle

To be used instead of the normal bundles until when are able to support multiple bundles of Scala
Fixes scala211 source feature label
Adds computeSourcePath documentation
Cleans up new features labels
Merge pull request #690 from skyluc/issue/multi-scala-support

multi Scala support
Adds support to detect available Scalas

Detects both bundled jars and multi-bundles installations
Merge pull request #693 from skyluc/issue/detect-multi-scala

detect multiple scala
better scala container addition tagging
Basic status handler for the Xsource flag
Switch ScalaPresentationCompilerProxy.failedCompilerInitialization to Status Handlers
Centralizing thread Management for handlers
Aggregate Initialization Failures in ScalaCompiler reference validation
Switch UIErrorReporter to status handlers
TIghter threading behavior for Handlers

They are now syncExec, and all but one synchronize on an exterior variable.
Indeed, event queues make them fire often :
- CompilerLaunchError : obviously
- ClasspathError : the Xsource modification triggers a classpath Check through the listener added to projectSpecificSetting.

TODO : instead of this, In ScalaProject's projectSpecificStorage, fire a java model Delta
	that can be caught by ScalaPlugin's elementchanged.
"Desired source level" toggle

- creation
- modification of the Xsource flag on modification