Redirection-related bugfixes.

This pull request contains the subset of #1913 which (IMNSHO) consists entirely of bugfixes, with no question about backward compatibility or what the best behavior should be.
- `Session.resolve_redirects` no longer crashes, when responses are
  being loaded in `stream=True` mode, if `Response.iter_content`
  is used to consume the entire stream before advancing the generator.
- `Response.history` is now always a list, not a tuple.
- Each response in a chain of redirects now has a filled-out history
  property, consisting of all responses up to but not including itself.

And I didn't bother mentioning it in HISTORY.rst, but `Session.send` doesn't create the redirection resolution generator anymore if it's not going to use it, and `resolve_redirects` doesn't extract cookies anymore that `send` has already extracted, both of which should make things ever so slightly more efficient.

Some of the new tests are pretty grody, and raise the question of whether the response-modification hook should really be _allowed_ to modify history, but there's specific code in `send` to support them, so  this seems to have been a desired feature...


IYNSHO? =D Are you sure you're not a Requests core developer? You certainly have the attitude of one. ;)

I'll try to code review this today, but shouldn't do it this morning, I have too many bugs at work. A quick note, though: we allow Response-modifying hooks to modify history because we use them for authentication. See the `HTTPDigestAuth` handler for an example. I'm very happy to remove hooks, but we'd need to do so in a way that allows not just Requests but everyone who's ever written a third-party auth handler to continue to be able to put 401s in the History. If you've got ideas, hop in the #python-requests channel on Freenode and run them past us. :cake:


New plan: I now think these bugfixes will be simpler and cleaner if I first make one API change (see pull request #1930).  In particular, the weird "`for r in gen: pass`" thing should be unnecessary.  Some replies to your comments, though:

Regarding `resp.content` throwing an error if `iter_content` has been used to consume the entire response body: yeah, I realize direct access to `resp._content_consumed` is unclean, but I am at a loss for a better idea.  Catching the exception struck me as inappropriate because `RuntimeError` is pretty vague: what if there were some other reason that might get thrown?  I'm open to suggestions. (And I'm definitely down with making the exception more specific.) Maybe a `resp.discard_content()` method? That might be generally useful, but it would be another API change.

Also on that point, it seemed like unnecessary process hoops to file a bug that I had already fixed, when I could just file the pull request instead. ;-)  I'm happy to do so if you want it in the database for tracking purposes or something, though.

Regarding response-modifying hooks, I don't really object to the feature, I just couldn't figure out what it was actually _for_. Now I know, I'll fix up the tests to do something less weird.

Regarding two-letter variable and argument names in tests, I will see what I can do about making the tests in general less cryptic, but sometimes a variable _should_ have a meaningless one- or two-character name: in this case, `ra` and `rb` are two currently-being-inspected entries in a list of Response objects the test is iterating over, and that is _all_ the semantics they have.  Response A, Response B.  Longer names would make the test _more_ cryptic, by increasing visual clutter and implying meaning where none exists.


(For clarity, all of the changes in here will come back on top of #1930, but this pull no longer makes sense.)