Add sbt build script.
Expose client job id in the API.

If anyone wants to log it for some reason.
Data structures for metric collection.

Not hooked to the client code yet. There's a lot of duplication with
the stuff in Spark's TaskMetrics, but since we don't have access to
the mutators from outside Spark, it has to be like this.

(Also the client interface is cleaner this way.)
Send metrics back to the client instance.

This is a little hackish, since it requires some communication between
the driver code and the job context so that jobs triggered by the user
can be monitored. It also requires user opt-in - right now an explicit
method call, although it could be changed to use a custom AsyncRDDActions
implementation instead (which would probably lead to more maintenance
in the long run).

There are also some question marks and some missing APIs in Spark to
be able to properly support this. But it's a start.

Finally, there is an open question about the safety of the current
RPC implementation: akka is asynchronous, although it says it does
guarantee messages arrive in order (which is why the code goes through
some trouble to make sure job results are sent only after all Spark
events related to the job are processed). But what about processing
the messages on the receiving side? Are they guaranteed to be processed
in order (by a single thread)?
Expose metrics through the Java API.

This just exposes the Scala types; hopefully they're usable from Java-land.
Also, the async APIs, needed for job monitoring by the client code, is not
very well supported from Java at the moment, so...