Implement request group and pause/resume support

Ok, here's an initial take on the whole pause/resume support for Picasso.

This PR adds a new API to `RequestCreator` that allows you set a group tag/marker to specific requests:

```java
Picasso.with(context)
       .load("http://example.com/image.jpg")
       .group("mygroup")
       .into(someImageView)
```

By default, all requests are associated with the default group defined as `Picasso.DEFAULT_GROUP`. This tag can be used to cancel, pause, and resume requests in the same group. To do so, you can use the following new APIs in `Picasso`:

* `cancelRequestGroup(String group)`
* `pauseRequestGroup(String group)`
* `resumeRequestGroup(String group)`

Maybe we should also have `pauseRequest(Target|ImageView|RemoveView)` and `resumeRequest(Target|ImageView|RemoveView)` for parity with the existing `cancelRequest(Target|ImageView|RemoveView)`. Let me know what you think.

Here are a few general notes on how this new API behaves:

1. When you pause a group, any new request for the paused group will not be attached to any `BitmapHunter` until the group gets resumed. In this case, the requests for a paused group will be queued in the `Dispatcher` (see `pausedActions` member).
2. If a request group is paused while there are already on-going requests for it (i.e. `BitmapHunter` is either running or waiting for its turn), the requests in the now paused group will get detached from any pending `BitmapHunter` immediately. If the affected `BitmapHunter` ends up with no pending actions, it will get canceled (see `performPauseGroup`).
3. If a request is canceled while its group is paused, it will be removed from the queue of paused requests accordingly (see `performCancel`). This might happen, for example, if a new request is initiated for the same target than a paused request.
4. A `BitmapHunter` might contain `Actions` from multiple groups at any given time. Not likely to happen in practice, but it's something we have to handle. This is why there's no 1-to-1 mapping between `BitmapHunter` and requests groups.

I should probably add some more tests for the new APIs. But I wanted to get some early feedback before spending more time on them. I've added a super simple scroll listener based on the new API. Works like a charm ;-)
Small nitpick: Should be "that must be managed"