Initial stab at a cleaner interface for Scala presentation compiler.

This probably needs a bit more polishing, but I put it out there so people get an idea of where we're heading.

* am `IScalaPresentationCompiler` interface with a smaller surface than `ScalaPresentationCompiler`
* convenience methods for `ask` calls. All calls in the interface create their own `Response` and return it
* simpler naming and cleaned up parameters

Stuff to do
- [ ] cleanup code using `ask*` across the board to use the simpler overloads
- [ ] remove the panoply of helper methods `withSource`, `withCompiler`, `withCompilerAndSource`, etc. They are just clutter and frankly a pain to use or debug. One simple way to get to the compiler is all we need.
- [ ] move existing code from package `compiler` to `internal.compiler`, and keep `core.compiler` only for API code.
- [ ] Rename `api.ScalaProject` to `IScalaProject` and remove package `api`. It turns out it's too confusing to have several files with the same name when working on both of them. I find this enough of a productivity killer to go for a naming convention that distinguish whether something it's API or not. Same goes for clients, my experience with Scala reflection showed it's better to know if you're dealing with "approved" API immediately (instead of dealing with `reflect.api.Symbols`, `reflect.internal.Symbols` and probably also `scala.tools.nsc.Symbols` or the like).
- [ ] See if methods in `ScalaJavaMapper` can be rewritten, simplified, removed, etc. They look really bad.
- [ ] rename `locate` to something more explicit, like `findDecaration` or the like

Some of these are easy to do, I just didn't have time to work on them, and I wanted to give an early preview to everyone before I leave for 10 days. :)

s/internal/syncExec/ in contradiction to asyncExec? And I don't see the reasoning behind the apply method, one syncExec would be more clear.