Unobivious HTTP Basic Auth behaviour

Hi there. I've just completed some [test](https://github.com/uthunderbird/clickhouse-sqlalchemy/commit/d21aba511df9e1fd94657d10383afa268a3f8d05), and decided to discuss a behaviour of `auth` option.

The solution I'm using now it's just a `password or ''`. I don't think it's a good approach.

## Expected Result

1. I know I can write something like `uthunderbird@example.com` to attach HTTP Basic Auth header to request to `example.com` in browser. Actually, it's true for any URI as I know. So it was pretty expected for me that this : `transport.auth = ('uthunderbird', )` will work for case if I don't want to send password.

2. The second idea was to write `transport.auth = ('uthunderbird', None)`, but it get a horrible result.

## Actual Result

1. `tuple is not callable`

2. I sent auth header with `dXRodW5kZXJiaXJkOk5vbmU=`, which means `'uthunderbird:None'`. Wow, such JSish.

## Reproduction Steps

```
python
import requests

a = requests.get('https://api.github.com/user', auth=('user', ))
```

```
python
import base64
import requests

a = requests.get('https://api.github.com/user', auth=('user', None)
base64.b64decode(a.request.headers['authorization'][6:]).decode()
```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.6.3"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "100020bf"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}```

(I'm pretty sure it's not required here, but ok)

Actually, the simplest thing we can do with this it's just document the usecase and tell that this is just the following of the principle of "explicit is better than implicit", so you should explicitly declare an empty password string, but it's an ideology conflict I think.

But at least None shouldn't be parsed as string in this case. It's really simple to fix it [here](https://github.com/requests/requests/blob/020f96577f8f44d06acc1ab699a7638653d91bd0/requests/auth.py#L31-L69). I think you can set Contributor Friendly tag to this issue after deciding which approach is more correct here.

Just experienced this as well from a downstream project using requests to send API requests with just an API key as the username and without a password.  Seeing the string `None` turn up as a string in the authorization header was unexpected.  I agree with @uthunderbird that whatever the behaviour, it just needs to be explicit.

What happens if you provide `''` as the password?

@kennethreitz An empty string as the password stays as an empty password in the auth header.  It's my current 'workaround'.

Hey everyone, sorry I didn't see this when it came through. You can find more information about this [here](https://github.com/requests/requests/blob/239ee194318e0b88d6a7b292ec4b68451ceefe68/requests/auth.py#L31-L37). This is a long known defect in Requests that has been addressed in 3.0.0 but we've left in place for backwards compatibility reasons. We will require an empty string (`''`) in the next major release and users will be met by a hard `TypeError` otherwise so that it's apparent.

Closing since this is resolved.