Add ssl_context parameter to Connection classes

After creating a shim SSLContext class in urllib3.util.ssl_, we now want
to start accepting instances of that class in general so users can take
advantage of some features provided only on certain versions of Python.

The first step is to allow users to pass ssl_context to both
HTTPSConnection and VerifiedHTTPSConnection and then pass these down to
the shim ssl_wrap_socket function in urllib3.util.ssl_. This does not
yet account for use with PyOpenSSL.

---

So this basically just works except for the fact that the following will raise an InsecureRequestWarning:

```python
import ssl
import urllib3
import urllib3.util.ssl_ as ussl


context = ussl.SSLContext(ssl.PROTOCOL_SSLv23)
context.load_verify_locations('../requests/requests/cacert.pem')
context.verify_mode = ssl.CERT_REQUIRED

manager = urllib3.PoolManager(ssl_context=context)
resp = manager.urlopen('GET', 'https://api.github.com/users',
                       preload_content=False)
```

Because the way I wrote `urllib3.util.ssl_.ssl_wrap_socket`, any settings on the the context set needs to be confirmed when creating the pool manager, e.g., the following works:

```python
import ssl
import urllib3
import urllib3.util.ssl_ as ussl


context = ussl.SSLContext(ssl.PROTOCOL_SSLv23)
context.load_verify_locations('../requests/requests/cacert.pem')
context.verify_mode = ssl.CERT_REQUIRED

manager = urllib3.PoolManager(ssl_context=context,
                              cert_reqs=ssl.CERT_REQUIRED)
resp = manager.urlopen('GET', 'https://api.github.com/users',
                       preload_content=False)
```

I think if we have `urllib3.util.ssl_.ssl_wrap_socket` return early when given a valid context, we won't break any prior behaviour, but I have yet to test that. Does anyone have any thoughts?
If we generate one here, we'll have to do most of what ``ssl_wrap_socket`` does in the ``__init__`` method of the ``VerifiedHTTPSConnection`` class. I'm not entirely certain if all of that logic that currently operates on the unified SSLContext object really belongs here. It may be a layer of indirection but it's also a nice separation of the concern of creating and configuring an SSLContext if none is provided.