Basic auth with integer username broken in 2.12.2

Previously, it was possible to set `auth` to something like `(42,'password')`. This has worked fine since before requests hit 1.0. 2.12.2, a patch release, broke this, causing failures such as the ones seen in this [Travis build](https://travis-ci.org/maxmind/GeoIP2-python/jobs/181427000).

I am not saying the new behavior is incorrect, but this is a breaking change.

This is similar but not the same as #3750,  #3736, and #3751.

This is different to the other three issues. Those three issues are all passing `None` type to `auth()` - You're passing an `int` object instead.

It would appear that they were all caused by 329a5cf though. 

What decisions those that maintain requests want to make is up to them though, just thought I'd help debug this.

A possible solution:
`codecs.encode("{0}:{1}".format(username, password).encode(), "base-64").strip()`
Not sure how versatile this is though

I've got a feeling this may fall under Requests' policy of "All header values must be a string, bytestring, or unicode.", since the Authorization field generated is a header, and the `auth` keyword is even discussed in the [Custom Headers](http://docs.python-requests.org/en/master/user/quickstart/#custom-headers) docs.

@Lukasa may have different feelings on this, but trying to permit non-string values here seems to have the same ambiguity issues we've tried to avoid elsewhere. Just like how `None` hasn't been permitted because `None` is cast to a string, when the user much more likely wants `""`, which will generate different auth values.

This gets to be another entry on my list of problems with semantic versioning.

We never intended non-string values to work here. I didn't care about the removal of support for `None`, because it was a colossally stupid value to allow that would basically never do what people expected. But at this point we begin to go off the rails again. And semantic versioning, read strictly, doesn't allow tightening of any check at all in a minor release.

I think the best thing to do is to re-add support for non-string values by checking for them and casting them to str explicitly. I don't want to hide it: I want us to put a big-ol' comment on top of it that says that this behaviour is dumb but we need to preserve it because people are relying on it. I then think we should catch-up master into proposed/3.0.0 and then merge a PR that *removes* that explicit cast.

Ok, right now master and proposed/3.0.0 are caught up. So if someone wants to make this patch, I can walk them through the two PRs we'll need.

For what it is worth, older versions of Requests did not work correctly with a username or password that were bytes on Python 3. They would produce authorization headers like `b'42':b'password'` when passed `(b'42', b'password')`; 2.12.2+ produce `42:password`.

@oschwald, yeah that was the intent (or I had understood it to be part) of #3673 which ended up causing the failure you're experiencing. The idea was to allow the user to supply unicode encoded strings (bytes) and we'll simply base64 encode bytes rather than messing with string encoding issues.

I can throw a patch for this together tonight or tomorrow morning if you're not interested in working on this.

For the master branch we want a check that says `if not isinstance(user/pass, basestring)` then we cast to `str`.

This will be resolved in a future release. =)