Save actions

This is not yet completely finished but because I already used it in production and it worked great so far I want to give you the possibility to play with it around as early as possible. In the following a short overview about what is included in this PR.

Features included:

- Java save actions do no longer work for Scala editors
- Instead there are even better Scala save actions. They look like this:
![sa-code](https://cloud.githubusercontent.com/assets/488530/3910926/763e033c-231c-11e4-9770-8703388e9799.png)

- A preference page in `Scala → Editor → Save actions` where the save actions can be enabled/disabled:
![sa-pref](https://cloud.githubusercontent.com/assets/488530/3910930/7c5b10d4-231c-11e4-8b39-4184373b7e73.png)

- A timeout for save actions (can be configured in the preferences). This timeout keeps the editor responsive but can't abort the computation of the save action (in the worst case it means that a non returning save action will run until termination of Eclipse in a background thread)
- Document driven (fast) and compiler driven (slow) save actions. The former usually operates in ~1-10ms, the latter more in ~50-timeout ms.

Design overview:

- Package `org.scalaide.extensions` contains new API+save actions
- Package `org.scalaide.core.text` also contains new API
- Package `org.scalaide.core.internal.{text,extensions}` contains implementations of the API
- Package `org.scalaide.ui.internal.editor` contains additions needed for save actions.
- A new save action needs to be a `trait X extends SaveAction with {CompilerSupport,DocumentSupport}`
- The save action needs to be enabled in `SaveActionExtensions.saveActionSettings` and in one of `SaveActionExtensions#{applyDocumentExtensions,applyCompilerExtensions}`

Drawbacks/TODOs:

- [x] The introduction of `ScalaDocumentProvider` broke several things
   - [x] Implicit highlighting (`SemanticHighlightingReconciliation`)
   - [x] Semantic highlighting extensions (participants)
   - [x] Toggle breakpoint (in `ScalaToggleBreakpointAdapter`)
   - [x] `BaseSemanticAction.refresh`
   - [x] All other things, which call `JavaPlugin.getDefault.getWorkingCopyManager.getWorkingCopy`
- [x] compiler accesses are not yet wrapped in askOption calls
- [x] API is not yet finished
- [ ] No tests for the save actions yet
- [ ] Resource leak when a save action never returns. I see possibilities to "reactify" the save action API because most functionality is hidden to users. But it is not yet implemented.
- [ ] Bug in AddMissingOverride: [1002221](https://www.assembla.com/spaces/scala-ide/tickets/1002221#/activity/ticket:)
I thought about it but didn't come up with a good solution. I have my own `Change` objects, that is why I couldn't reuse the code from scala-refactoring. I want to play around with some cancellation conditions anyway, where own code is useful, but I can't say at the moment to what extend it makes sense to move the changes to scala-refactoring.