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
I'm also wondering about the value of such levels of indirection.

I think the biggest contribution of this PR is documenting and "filtering" all utilities methods we have. I don't really like the level of boilerplate traits and implementations bring. The alternative is to have top-level objects as before, and mark non-API methods as `private[org.scalaide]` or the like.

@skyluc, @sschaef, @huitseeker, what do you guys think?