JCloud ProfitBricks provider implementation

Hi! This implements most of ProfitBrick's API. I look forward for your comments, suggestions, and revisions.
So this seems to be YAATS (Yet Another Api That Sucks :D). This is something that needs to be configured a bit different.

jclouds by default tries to retry failed requests using a customizable strategy. It first [sends the request](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L96) and decides if it must be retried [based on the response code](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L104-L111). If the response is a 2xx, then the operation just returns and the `ResponseParsers` (such as the `XMLResponseParser`) are invoked to transform the request in the right Java entity returned by the API.

However, if after the configured retries, the response is still a failure, then the configured `ErrorHandler` (the PB error handler in this case) [will be invoked](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L135) to populate the right exception. That exception is [thrown later](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L125-L126) and [captured and transformed](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/InvokeHttpMethod.java#L94) if the API method defines a `Fallback`, so the right result is returned.

With this bit of context in mind, the `XMLResponseParser` won't be invoked if the response is a 500, as an exception will be propagated before. The problem here is that you need to read the response body to actually know if the request failed (YAATS!). The current code only checks the response status, so you'll have to override a bit of code to populate the proper response code.

The DigitalOcean API v1 has the same problem, and you can copy how it fixes it. It defines a [subclass of the JavaUrlHttpCommandExecutorService](https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java) that inspects the body of the response and populates the right response code. The configuration is done [here](https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/config/DigitalOceanHttpApiModule.java#L48-L56) and [here](https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/DigitalOceanApiMetadata.java#L70), so it is properly bound to the Guice context. With that in place, the response body is read and the response code set accordingly, so the default jclouds mechanisms to retry or fail the requests (and the subsequent invocations of the response parsers, only when the request really suceeds, or the fallbacks) work as expected.

It is not optimal, because when the response is a 2xx you'll read the body twice (one to determine if there is an error, and a second one in the response parser) and often that means that the response body must be buffered, if the InputSteram for the body is not repeatable, but it is the less intrusive solution you have with APIs like this.