An API for ScalaProject

Submitted early to garner comments and allow for discussion.

- I believe the members provided in the API package are the absolute maximum we should commit to supporting at the moment.
- 'Immutable' in comments has been used as
  + advice for extension
  + a substitute for a comment on thread safety
- I have branches for all the plugins:
  + [scala-search](https://github.com/huitseeker/scala-search/tree/issue/ScalaProjectAPI) (passes all tests)
  + [scala-worksheet](https://github.com/huitseeker/scala-worksheet/tree/issue/ScalaProjectAPI) (passes all tests)
  + [scalatest](https://github.com/huitseeker/scalatest-eclipse-plugin/tree/issue/ScalaProjectAPI) (fails no more tests than next-best branch)
  + [scala-ide-play2](https://github.com/huitseeker/scala-ide-play2/tree/issue/ScalaProjectAPI) (passes all tests, based on https://github.com/scala-ide/scala-ide-play2/pull/216)

This splits contributions into many commits for clarity / prereq exposure. You should expect a squash of some of the early commits before merge.
Actually, I think the order is important, so I'd keep it as a `Seq` in this case. We need to see if this holds, but in Sbt there's a number of *configurations*: compile, test... It became usual to have a third one, *macros*, under `src/macros/scala`, and order compilation such that macros are built first, and are available to compile and test.

I think we should (eventually) support that by building each configuration (meaning src-ouput pairs) separately, like Sbt does. There's even a ticket: [#1001633](https://www.assembla.com/spaces/scala-ide/tickets/1001633).