Fix how we test fallback to latin-1 reason encoding

This was terribly broken and found while merging master into proposed/3.0.0


Sorry I let Python 2 slip through the cracks. I am, however, still seeing a failure in python 2.7.10 on multiple systems with this merge. The issue appears to be that we're handing a unicode string in Python 2 to the HTTPError which is producing an "unprintable HTTPError" message when it can't be decoded to ascii. This was also present in the original test in PR #3385, we just weren't testing the string. Encoding the actual [error message](https://github.com/kennethreitz/requests/blob/master/requests/models.py#L862-L869) string before passing it to the exception fixes this problem in Python 2.

e.g.

``` python
if http_error_msg:
    if is_py2:
        http_error_msg = http_error_msg.encode('utf-8')
    raise HTTPError(http_error_msg, response=self)
```

**Edit:** @sigmavirus24 can you confirm this is failing for you in Python 2 still and that my tests aren't borked?

**Second Edit:** I can't find anything functionally different in this PR from pre-#3557 except that we're now comparing a string object with a unicode object in the final assert statement. I'm not particularly tied to the encoding ordering, but I do think that this test should match the other unicode tests above it. Is there a reason that the encoding needs to be done during the assertion (bytes->str) instead of at the beginning (unicode->bytes)? These will always be unicode strings, so I'm not sure if we gain anything from dropping the reason phrase down to latin-1 during the final assertion (other than it needs to not be bytes). Apologies if I'm missing something obvious.

This would be [my proposed solution](https://github.com/nateprewitt/requests/commit/0cf4e700d2ce30c9422d788d705c5496d5401d3d) for fixing the failing tests. Like I said, I'm not tied to reverting but I think related tests are easier to understand if they share common pieces.


@nateprewitt this wasn't working on Python 2 _or_ Python 3 before but this passes for me on Linux and OSX. What are you testing on?


Odd, it's been working with 3.5.1  on my system since I opened the PR. When you opened this this morning, I checked 2.7.10 on OSX 10.10 and it is not working. The call to str(e) with a unicode string produces an `UnicodeEncodeError: 'ascii' codec can't encode characters in position...` response. I'm reproducing this with this test code, which mimics how we're [passing the message to HTTPError](https://github.com/nateprewitt/requests/blob/master/requests/models.py#L862-L869). The string will always be unicode.

``` python
e = Exception(u'testöö')
print(str(e))
```

Perhaps this is due to something I've configured in all of my environments though. I'm encountering the same errors with with 2.7.12 on RHEL6.


Also if you look at the [test](https://github.com/sigmavirus24/requests/blob/42d4eaf6eaad8b43e1048b8ac06aec760c2285ab/tests/test_requests.py#L1016-L1023) immediately above this one, it is very similar in structure except for the string comparison at the end.

#3557 passes in the identical bytes to what was passed prior to the patch:

``` python
reason = u'Komponenttia ei löydy'
bytes_reason = b'Komponenttia ei l\xf6ydy'
reason.encode('latin-1') == bytes_reason
```

 and they're both comparing an identical unicode reason with a unicode error message.

``` python
reason = u'Komponenttia ei löydy'
bytes_reason = b'Komponenttia ei l\xf6ydy'
bytes_reason.decode('latin-1') == reason
```

 Do you know what the test was failing on in Python 3? 


@sigmavirus24, here's some tox runs on blank travis instances displaying what I'm seeing locally.

Pre-#3557: https://travis-ci.org/nateprewitt/requests/builds/158050706 (87f9693)
Post-#3557: https://travis-ci.org/nateprewitt/requests/builds/158050156 (2041adb)
My Proposed Patch: https://travis-ci.org/nateprewitt/requests/builds/158051134 (0cf4e70)


Alright @sigmavirus24, I think I've finally gotten to the bottom of the confusion here (or most of it). It looks like you wrote and commited [a separate test](https://github.com/kennethreitz/requests/blob/proposed/3.0.0/tests/test_requests.py#L1054-L1069) for proposed/3.0.0 than you submitted here, which does in fact pass on all versions. This patch as it stands on master though is functionally identical to the test beforehand and still fails for Python 2. 

We could move the test from proposed/3.0.0 over to master to fix the problem, but I feel like it may be unnecessarily verbose. You perform an identical check by simply switching `str(e)` to `e.value.args[0]`. I've updated my commit (39e8c0d) to use this instead, still with the reversion of the encodings for the reasons listed in the comments above. As I said before, not tied to that, but I'd rather keep the tests similar if possible.

I'm fairly confident this is the correct approach at this point, but please let me know if you see something I'm not. I'll open this as a PR tomorrow afternoon unless you'd like to make the changes yourself.

Here's the [Travis build](https://travis-ci.org/nateprewitt/requests/builds/159784486), if you wanna take a look.