Improved pagination in GCE

This pull request improves the pagination in GCE so it no longer sucks :D The main changes are:

* Removed all `listFirstPage` and similar methods from all APIs.
* All *list* methods have two forms: one to list all records that returns a `PagedIterable` (no params), and one to get a concrete page that accepts a `ListOptions` object.
* The `ListPage` object representing a single page has been refactored and improved and now has a convenience method `toPagedIterable`, that allows converting it to iterate over the pages after a filter operation or similar.
* Refactored all parsers to accommodate the new pagination logic.

In summary, every API only has the minimum and meaningful methods to get a list of records, and the pagination domain objects have been reworked to make it trivial to iterate over the pages.

I've also removed most of the warnings in the project.

/cc @ccustine @danbroudy Could you give a try to the branch and run the live tests? Your feedback on how the new pagination methods look like from a user point of view is appreciated too :)
/cc @adriancole Your feedback is also welcome :)

If we want to be able to build a PagedIterable given  single page (IterableWithMarker or ListPage) we need the advancing function. Wether it is already set inside the list object or we use an alternate method to build it (such as [PagedIterables#advance](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/collect/PagedIterables.java#L68-L75)) we need to hold a reference to that function as long as the List object exists; otherwise it won't be able to lazily fetch new pages as they are needed.

This said, I tried to hide the advancing function from users because it might be *difficult* to get:

* Users calling a list method would need some deeper knowledge on how it works internally to be able to pick the right function.
* When directly building the Api you don't have access to the Injector (however, if you build a Context such as the compute one, you have the `utils().injector()` method), so there might not be an easy way to get a proper instance the right function to use.

That made me go for the `ListPage` approach having the `toPagedIterable` method and already having a reference to the advancing function.

Just to make sure I understand your concern: we could be leaking the reference to the advancing function only in the case the user does not want to advance to the next page. When getting the "entire" list provided by the PagedIterable, the advancing function is always needed. IMO, the former use case might not be the most used one, as the method that returns the ListPage is the one used when filtering resources or performing searches, but that's only a guess; we really don't know which of both methods will be used more.

I see two options to move forward:

* Keep the ListPage as-is, in favor of api usage simplicity, but with the possibility of holding an unneeded reference to the advancing function.
* Get rid of that ListPage and make the api methods just return a regular `IterableWithMarker`. This will make users have to use the existing `PagedIterables.advance` to build a Pagediterable, and manually get the advancing function by some mean.

Am I getting the picture? WDYT?