An API for Util methods

This creates and documents an Utils API for Utility methods used frequently and externally, and switches internal code to use them. This covers all usages in the plugins (and relevant PRs will follow soon)

**All** the remaining occurrences of util.internal usages are as follows:

- Out of the Scope of this PR
  + `org.scalaide.util.internal.eclipse.RegionUtils`

- We don't want to make this one public (either it should not be exposed to plugin implementors, or it's not used enough to justify being in an API)
  + `org.scalaide.util.internal.Commons`
  + `org.scalaide.util.internal.CompilerUtils`
  + `org.scalaide.util.internal.eclipse.AnnotationUtils`
  + `org.scalaide.util.internal.eclipse.EmptyRegion`
  + `org.scalaide.util.internal.eclipse.ProjectUtils`
  + `org.scalaide.util.internal.eclipse.TextEditUtils`
  + `org.scalaide.util.internal.FixedSizeCache`
  + `org.scalaide.util.internal.ReflectAccess`
  + `org.scalaide.util.internal.SbtUtils`
  + `org.scalaide.util.internal.scalariform.`
  + `org.scalaide.util.internal.SettingConverterUtil`
  + `org.scalaide.util.internal.ThreadUtils.withLock`
  + `org.scalaide.util.internal.ui.AutoCompletionOverlay`
  + `org.scalaide.util.internal.ui.Dialogs`
  + `org.scalaide.util.internal.ui.UIStatusesConverter`

- Makes use of a particular member of the internal trait that we don't want public, "normal" usages have been APIzed

  + `org.scalaide.util.internal.eclipse.EclipseUtils.prepareJob`
  + `org.scalaide.util.internal.eclipse.EclipseUtils.RichPath`
  + `org.scalaide.util.internal.eclipse.EclipseUtils.RichWorkbench`
  + `org.scalaide.util.internal.ui.DisplayThread`
  + `org.scalaide.util.internal.ui.UIThread`

=========================
Edit: the dependent PRs are:
- https://github.com/scala-ide/scala-search/pull/102
- https://github.com/scala-ide/scala-worksheet/pull/202
- https://github.com/scala-ide/scala-ide-play2/pull/229
1 - How do you deal with namespace ?

2 - Changing a method from private to public is low-consequence in our internals, but high-consequence in the API. How do you separate those important API methods in our objects from the rest ?
How do you mark the compatibility burden that comes with modifying one such method?

3 - Some methods in the implementing objects really should be called directly (as an exception) from outside of their own module — so they have to be public—, but should not be exposed to plugin implementors to call (e.g. `ScalaCompilationUnitEditor`'s use of `DisplayThread`, or `prepareJob`)