Client refactoring

Hi Garreth

Consider this a work in progress, for your review. Don't merge yet, as I'm far from done.
I'll continue to commit things to this branch so this PR stays up to date.
Authentication is quite complex, as in some cases the following flow may happen:

1. Request is made
2. Server returns 401
3. Client goes to OAuth server to ask for a new bearer token
4. Client retries request from step 1

In this particular scenario, the Promise of the first request should only be fulfilled after step 4, and never reject. The whole re-authentication flow is invisible to the user of the api.

I don't have any issues storing the information in the account object instead, but then I feel that the client should have access to this object. This sounds pretty reasonable to me, if we consider the account object as a value object where we can also cache other things (such as the calendar-home-set and other urls).

As for raw xml data.. on a high level i made it work as follows:

1. You construct a request
2. Give it to the client
3. Client fulfills promise with a response

The response object is now indeed pretty 'raw' in that it only gives back the full response body.
However, during step 1 it's possible to tell the client which 'class' to use for the response.

During propfind, calendar-query and other requests that expect a multistatus response, the client can then construct lib/response/multistatus which should automatically parse the xml response and give access to the responses and their properties.