Fix the additional newline generated by iter_lines() caused by a '\r\n' pair being separated in two different chunks.

When a "\r\n" CRLF pair is splitted into two chunks accidentally, iter_lines() generates two line breaks instead of one. This patch fixes the incorrect behavior and closes issue #3980.

@Lukasa Thanks for the review and I already modified the code by following your instructions.
However there seems to be some issues with the unit tests. I'll take a look on them.

@Lukasa While trying to fix the unit tests, I noted that treating "\r\n" as two line breaks is actually the intended behavior based on the current unit tests. While this behavior is incompatible with the default of python (universal newline) and is not explained in the requests API doc either, what `delimiters=None` does should be well defined and documented before we try to fix this. The unit tests should be fixed to reflect the change as well.

* If treating "\r\n" as two line breaks is intended, then the fix is avoiding the use of splitlines() and split the lines on either '\r' or '\n' outselves. Then, make this documented in the API doc.
* Otherwise, we should simulate the behavior of splitlines() and follow python universal newline handling, and fix all the unit tests and API doc to reflect this behavior change.

Either way, the current code needs some fix since different chunk size can yield different results.

Another issue with the current uint tests is it only works with python2. For working with python3, delimiter should be bytes rather than str if decode_unicode is not True, which is not addressed in the unit tests.
@Lukasa Your suggestions are needed. Thank you.

The unit tests should be updated: `splitlines` is clearly intended to be part of the behaviour of the code and so the unit tests as written should be considered as codifying the v2 behaviour, rather than guiding the v3. We can change them for v3.

>  For working with python3, delimiter should be bytes rather than str if decode_unicode is not True, which is not addressed in the unit tests.

Yup, that should change as well.

It seems sensible to have the test data default be in bytes since that's what we should be receiving from urllib3. We can have a `parametrize` toggle if we want to test both True and False for `decode_unicode`.

@Lukasa @nateprewitt Just fixed all of the unit tests and the mentioned chunk[1:] problems. All related tests should pass now. Also provide a small test program to demonstrate the bug.
```
import requests

test_content = b"line1\r\nline2"

def mock_iter_content(chunk_size=1, decode_unicode=None):
    for i in range(0, len(test_content), chunk_size):
        yield test_content[i: i + chunk_size]

r = requests.Response()
r._content_consumed = True
r.iter_content = mock_iter_content

assert list(r.iter_lines(chunk_size=6)) == test_content.splitlines()
```
Thanks!

# [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=h1) Report
> Merging [#3984](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=desc) into [proposed/3.0.0](https://codecov.io/gh/kennethreitz/requests/commit/73456b00485a59c6318b36724e3a1ef663e07b85?src=pr&el=desc) will **increase** coverage by `0.04%`.
> The diff coverage is `100%`.

[![Impacted file tree graph](https://codecov.io/gh/kennethreitz/requests/pull/3984/graphs/tree.svg?token=mZGswIiXLa&src=pr&height=150&width=650)](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=tree)

```diff
@@                Coverage Diff                 @@
##           proposed/3.0.0    #3984      +/-   ##
==================================================
+ Coverage           89.44%   89.48%   +0.04%     
==================================================
  Files                  15       15              
  Lines                1932     1941       +9     
==================================================
+ Hits                 1728     1737       +9     
  Misses                204      204
```


| [Impacted Files](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [requests/models.py](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=tree#diff-cmVxdWVzdHMvbW9kZWxzLnB5) | `94.33% <100%> (+0.11%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=footer). Last update [73456b0...64ff760](https://codecov.io/gh/kennethreitz/requests/pull/3984?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


@Lukasa Thanks for the detailed review. All problems are cleared now.

@Lukasa Done! :)

> So this is now looking good except for my possible concern about the readability of our two alternative approaches.

I think I'm missing something. I've looked through the PR but I don't see alternative approaches or readability issues. This could just be the woefully immature GitHub Review system hiding it from me though.

Yeah, it is. See [this discussion](https://github.com/kennethreitz/requests/pull/3984#discussion_r112929801).

@Lukasa Fixed as suggested by @sigmavirus24 .


@Lukasa @sigmavirus24 git squashed. Thanks for your patience.