removing redundant logic from prepare_content_length

# Background

So while working on #3535 I noticed that `prepare_content_length` will be fairly redundant after the patch is merged. I was going to push the abbreviated version of `prepare_content_length` into #3535 but found some inconsistencies in how we're currently handling Content-Length.

So here's a quick rundown of what I've found, and what it seems like _should_ happen.
- #957 addressed #223 and added Content-Length to _everything_.
- #1142 amended this to NOT send Content-Length with GET/HEAD requests (Issue #1051)
- #2329 addressed the issue of not being able to override Content-Length with a custom header (Issue #2329)

From this, I'd expect:
- Content-Length to be set on all requests that are not using a HEAD/GET method.
- If a Content-Length header exists, that it remains untouched when sending a request.
# Next Steps

Currently, setting a body on a request will override the custom Content-Length header. The test implemented in #2329 doesn't test the code path with a body. I've added that test and the required logic to make it succeed. However, the solution attached here is not my preferred approach, rather the closest to the old functionality of prepare_content_length.

_Ideally_, I think that any call to `prepare_content_length` will do just that, set the Content-Length. That way if someone updates the body on a PreparedRequest, they can use `prepare_content_length` without having to delete a header, or recreate the object. This approach would require moving `if self.headers.get('Content-Length') is None` up to `prepare_body` and `prepare_auth` to run the overwrite check there.

This has the issue of causing latent errors though, if someone decides to use `prepare_content_length` elsewhere without the existence check. So if we're concerned about that being a possibility, then I think `prepare_content_length` should instead have an `overwrite` param which will bypass the [check](https://github.com/kennethreitz/requests/compare/master...nateprewitt:new_prepare_content_length#diff-afd5aad80649cdfae687bee05242c8faR472) to see if the header exists.
# 

This PR is two tangentially related fixes (abbreviating prepare_content_length post #3535 and fixing inconsistencies in how we handle Content-Lengths). This SHOULD NOT be merged and probably doesn't need to even be addressed until after #3535 is merged.


@Lukasa whenever you've got a chance, could I get your thoughts on this?


Ok, I'm going to do an abridged reframe for this PR because the first post is a bit wordy.

Now that we've updated `super_len` in #3535, `prepare_content_length` is mostly redundant and a space were we could accidentally end up with differing functionality in the future. I'm proposing we consolidate the method to the code below, which will have equivalent logic:

``` python
    def prepare_content_length(self, body):
        if body is not None:
            length = super_len(body)
            self.headers['Content-Length'] = builtin_str(length)
        elif self.method not in ('GET', 'HEAD') and self.headers.get('Content-Length') is None:
            self.headers['Content-Length'] = '0'
```

The second issue is the functionality over 'Content-Length' override, which I addressed [above](https://github.com/kennethreitz/requests/pull/3545#discussion_r79694617). They seemed somewhat related at first, which is why I raised it at a single PR.


I think, given my comment above, that we should restrict ourselves to the redundancy removal for now. Overwriting Content-Length is, IMO, a severe misfeature, and I'm willing to make that case pretty forcefully to Kenneth if he needs convincing. ;)


Ok, that's good enough for me. For cataloging purposes, would you prefer I pare this PR down to just the redundancy fix, or close this and open a new one?


Let's pare this one down. =)


I'd like to be included on this review prior to its merging. We (three) have made enough serious problems in the content-length portion of requests that it needs as many reviews as we can afford.


Ok, things are pared down. The patch is now pretty simple.

The logic for file-like objects (with seek/tell) is now in [`super_len`](https://github.com/kennethreitz/requests/blob/d7227fbb7e07af35f23a0d370ab3b01661af9e40/requests/utils.py#L78-L103). I'm removing [this chunk](https://github.com/kennethreitz/requests/blob/d7227fbb7e07af35f23a0d370ab3b01661af9e40/requests/models.py#L478-L483) since it is now redundant. I'm also adding two tests to verify that Content-Length is set to 0 appropriately.

@Lukasa, @sigmavirus24 feel free to take a peak when you have a moment.


@Lukasa it looks as though @nateprewitt pushed new changes after your approval. Care to re-review?


Woops, forgot to approve this. :)