Feature request: support options for suppressing InsecurePlatformWarning and requests.exceptions.InvalidHeader

I think the requests is designed for keep high security. But when prototype use or trial use, that restrictions are pesty. Especially two errors below.
- InsecurePlatformWarning: A true SSLContext object is not available
- requests.exceptions.InvalidHeader: Invalid return character or leading space in header

I'll show the code below.

``` python
...
# [Pesty Case-1]
# This application-specific header includes spaces and marks,
# but the requests outputs 'requests.exceptions.InvalidHeader' error.
headers ={
    "Authorization" : " Basic q3io5yaFA="
}
# [Pesty Case-2]
# If you use 'verify=False' option, the requests outputs 'InsecurePlatformWarning' warning.
r = requests.get(url, headers=headers, verify=False)
...
```

I think supporting a option for suppressing them is benefit, like this.

```
r = requests.get(url, headers=headers, disable_security_assertion=True)
#                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ like this!
```

What do you think?


Thanks for this report! However, we will not be disabling either of these features.

Firstly, the warning. You've identified it as an `InsecurePlatformWarning`, but I suspect it's actually an `InsecureRequestWarning`, as `InsecurePlatformWarning` is not caused by passing `verify=False`. This warning is intended to be a reminder to you to remove `verify=False` as soon as feasibly possible. There is _almost never_ a reason to pass `verify=False`. If you're using a self-signed cert on your service, you can simply download the self-signed certificate using a web browser or OpenSSL, save it to a PEM file, and then pass the path to that file to `verify` instead. This will prevent you bumping into errors. Certainly you should never allow your software to enter production with `verify=False` in place. That's why this error is there, and providing an extra switch to easily defeat it would entirely remove the purpose of it.

Secondly, the exception. This exception is a hard fail, and again we will not provide tools to circumvent it. You should _never_, under _any circumstances_, emit a header with leading whitespace. While in principle such a header is syntactically valid HTTP/1.1, in practice other HTTP/1.1 implementations frequently interpret such a header incorrectly, most commonly by failing to parse it entirely. This opens up the possibility of subtle errors or request smuggling attacks, and the risk is doubly strong in the case of any code that passes user-specified data to Requests. Given that there is no _legitimate_ purpose for disabling this test (there is no reason you should ever need leading whitespace in your header field value), there is no reason to make this bypassable. Simply adjust the code that is generating your headers. =)


@Lukasa Thank you for response.

The REST API server needs a header leading whitespace. In this system, we must use the header field `"Authorization" : " Basic (SECURITY-TOKEN)"` for the authorization to the system. Spaces also must be needed! :sob: 

I think this system's REST API design is so bad :sob: 


My goodness. Really?

If you absolutely _must_ do that, you can use the [PreparedRequest flow](http://docs.python-requests.org/en/master/user/advanced/#prepared-requests) which will let you modify headers _after_ we have prepared them, at which point we won't do further validation.

Boy that's silly though. =P