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 funcitonality 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:
- [ ] Directory installation tests (@skyluc)
- [ ] Scala Installation switches tests (@huitseeker)
- [x] ~~Classpath Container edition window should set the initially selected container to the current one~~
- [ ] 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.~~
- [ ] A project with differently-versioned libraries ("cross-compiled" case of the classpath check, e.g. sbteclipse) should offer a Scala installation preference change.
- [ ] A project with the wrong scala-library ("previous version" case of the classpath check, currently suggesting `-Xsource`) should offer a Scala installation preference change
- [ ] Detection of a no-longer-valid scala installation (currently falling back to desired source level or platform) should offer a Scala Installation preference page..

Does this anonymous class have a sensible implementation of quals/hashcode? The `classLoaderStore` cache uses the installation as a key, so I'm wondering if this is going to lead to many cache misses (and many classloaders created). At some point, all `ScalaInstallations` were case classes, so equality came "for free".