Handle space-separated values in NO_PROXY

Since there is no standard for the NO_PROXY environment variable allow values
to be comma- and space-separated values.

Hi @michael-o, I did a bit of digging. While `NO_PROXY` has no formal spec, the majority of tools seem to be in agreement on its usage. I've been unable to find documentation for any common web tool that uses space-delimited lists for NO_PROXY. Curl, which we usually use as our model in situations like this, [calls it out](https://curl.haxx.se/docs/manpage.html) specifically as a "comma-separated list of hosts/domains".

Was there a reason you needed spaces introduced here?

@nateprewitt, yes flexibility in some degree: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247947. Since curl works, I see no reason that py-requests shouldn't. I see no apparent harm by merging this.

@nateprewitt Do you see any change to have this merged? I will happily rebase if required.

Ping...

Curl documents as a comma separated list, I dont think we should do any different. Going to close this. 

Well, a decision at least. Although my change is non-invasive. I would also concur your statement:
1. Have a look at this: https://github.com/curl/curl/blob/648712eec1eedb05965b9b4d6dd457bda5d70481/lib/url.c#L2136-L2145
2. This works for me with curl: `NO_PROXY=localhost .siemens.net .siemens.com .siemens.de`

As it seems the space is happily accepted:
```
osipovmi@deblndw011x:~
$ curl -I --verbose https://github.com
* Uses proxy env variable NO_PROXY == 'localhost .siemens.net .siemens.com .siemens.de'
* Uses proxy env variable HTTPS_PROXY == 'http://194.145.60.1:9400'
*   Trying 194.145.60.1:9400...
* Connected to 194.145.60.1 (194.145.60.1) port 9400 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to github.com:443
> CONNECT github.com:443 HTTP/1.1
> Host: github.com:443
> User-Agent: curl/7.74.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection Established
HTTP/1.1 200 Connection Established
< Proxy-Agent: Zscaler/6.0
Proxy-Agent: Zscaler/6.0
<

* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: none
*  CApath: /etc/ssl/certs/
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CONNECT phase completed!
* CONNECT phase completed!
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
*  start date: May  5 00:00:00 2020 GMT
*  expire date: May 10 12:00:00 2022 GMT
*  subjectAltName: host "github.com" matched cert's "github.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: github.com
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< date: Tue, 05 Jan 2021 08:48:22 GMT
date: Tue, 05 Jan 2021 08:48:22 GMT
< content-type: text/html; charset=utf-8
content-type: text/html; charset=utf-8
< server: GitHub.com
server: GitHub.com
< status: 200 OK
status: 200 OK
```

Is that sufficient to change your mind?