Unsatisfiable byte range request (416), but iter_content() still provides data

## Summary

I accidentally requested a byte range that was out of the targeted resource's range, but iter_content() still provided bytes despite receiving a 416 error code.  Apparently, in addition to the 416 error code, the server is returning an unrequested html document describing a 416 error code.  I've read [Since RFC 7233](https://tools.ietf.org/html/rfc7233), but I'm unable to tell what should happen.

## Expected Result
Either 
* (a) the server is allowed to return something like that, and `requests` is behaving correctly by receiving the data.  The off-by-one error that caused the bad request was my fault, and I should have been more diligent about checking status codes.  Close the issue, and I can go sit in the corner of shame.
* (b) the server is not allowed to return unrelated content with a 416, and `requests`  should be catching the error
* (c) the server is allowed to return unrelated content with a 416, but it's such bad form that `requests`, as "HTTP for Humans," should warn or throw an error.

## Actual Result

I was streaming a zip file, and i accidentally requested a start and end past the end of the file.  I appended the results from iter_content() to my file (Windows ended up ignoring the extra bytes, but that's not the point).
The reproduction code shows the extra data that I received in a 416:
```
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>416 Requested Range Not Satisfiable</title>
</head><body>
<h1>Requested Range Not Satisfiable</h1>
<p>None of the range-specifier values in the Range
request-header field overlap the current extent
of the selected resource.</p>
</body></html>
```

## Reproduction Steps

```python
import requests
import sys
ais = 'https://coast.noaa.gov/htdata/CMSP/AISDataHandler/2017/AIS_2017_01_Zone10.zip'
requests.get(url=ais, stream=True)
#Out[4]: <Response [200]>
requests.get(url=ais, stream=True).headers['content-length']
#Out[5]: '941900127'

header={'Range':'bytes=%s-%s' % (941900127,941900127)}
req = requests.get(url=ais, stream=True, headers=header)
for chunk in req.iter_content(chunk_size=1):
   if chunk:
       sys.stdout.write(chunk)
 ```

## System Information
```
C:\Users\600301>python -m requests.help
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": "2.4.2"
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.5"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "1010101f",
    "version": "18.0.0"
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": true
}
```


Requests does not and can not (within reason) protect you from yourself or a misbehaving server. We don't introspect headers to guess what you're trying to do (in this case a range request) and we don't automagically raise exceptions for error-class status codes. We expect users to check status codes or use `raise_for_status()` if they want an exception in those cases.

Unfortunately, there's not much we can reasonably improve for your use-case without causing immensely frustrating bugs for someone else. (I've investigated) Part of what makes the Requests API so appealing to so many is what makes it so frustratingly difficult to do things that might be convenient to a narrower percentage of our users, like in this very case.