Scala Installations support stage II : choose your own installation

This is here to help advance review for the [second phase](https://docs.google.com/a/typesafe.com/document/d/10YvZQaPGdRepMwEaMTMU_-Ij-_y3Gg8ui2Usgv1tIsk/edit?usp=sharing) of the Scala Installations support 

The basic functionality is here, meaning you can choose a scala installation instead of a source level, and add your own scala installation as *just a bunch of jars*. A few missing items that will be added quickly:
- [x] ~~Directory installation tests (@skyluc)~~
- [x] ~~Scala Installation switches tests (@huitseeker)~~
- [x] ~~Classpath Container edition window should set the initially selected container to the current one~~
- [x] ~~Classpath Container edition should prohibit edition and redirect to compiler settings if both compiler and library containers are on classpath~~
- [x] ~~in Compiler Settings, Scala Installation combo field selection should update the Apply button and the dirtiness.~~
- [x] ~~A project with differently-versioned libraries ("cross-compiled" case of the classpath check, e.g. sbteclipse) should offer a Scala installation preference change.~~
- [x] ~~A project with the wrong scala-library ("previous version" case of the classpath check, currently suggesting `-Xsource`) should offer a Scala installation preference change~~
- [x] ~~Detection of a no-longer-valid scala installation (currently falling back to desired source level or platform) should offer a Scala Installation preference change.~~
- [ ] Change the "Installed Scalas" name on the workspace-wide install page to smoething else
- [ ] Adapt w.r.t  https://github.com/scala-ide/scala-ide/pull/733


Yes. There's a listener on that property change which given a wrong astral alignement triggers a check too early (in turn triggering the Scala Install dialog we're talking about), even though the property change is supposed to fix the issue in the first place.