Add wrapper classes for InputStream and Socket

This is in preparation of supporting SNI when a client specifies an IP address
in a CONNECT request, instead of a DNS host name.

The `CONNECT ip:port HTTP/1.0` behavior was observed with certain Android
clients. In order to reproduce it locally, I setup a socat instance that
transparently proxies all requests to WebScarab with an IP address.

    socat TCP-LISTEN:443,fork PROXY:127.0.0.1:178.21.112.251:443,proxyport=8008
    curl -4 -vvv -k --resolve lekensteyn.nl:443:127.0.0.1 https://lekensteyn.nl
Enable SNI support for WebScarab in the server role

Before this patch, WebScarab will always create a certificate based on the host
given in the CONNECT line. Some clients send an IP address in the CONNECT line
and put the domain name in the TLS ClientHello message. This causes a mismatch
between the name on the certificate (IP address) and the expected value (a
domain name).

Since the host name passed to the negiotiateSSL (SSLSocketFactory.createSocket)
is used for the certificate name, the real host name must be determined before
that (before the SSLSocket is set up). Therefore, wrap the socket in a
WireSocket such that the ClientHello message can be captured and the Server Name
can be extracted.

Once a SNI host name is found, the `_base` URL is rebased on this host name.
This changes the certificate name and replaces the host that is visible in the
UI and logs.
Copy CN and SAN from server certificate.

Previously, the following happens for a connection setup:
1. Client sends CONNECT example.com:443
2. Server creates a certificate for example.com and gives it to the client.
3. Client continues TLS handshake and sends the actual request, encrypted.
4. Server connects to example.com:443, established a secure connection and
   performs the request. It then writes the response back to the client.

This has generally worked well, but I found an Android client that connects to
an IP address (192.0.2.0:443) and does not use SNI to make clear that it
actually wanted "example.com". Instead, it connects to an IP address and
compares the names on the certificate with a string in the application code.
Since my goal is to make WS as transparant as possible, I changed the order to:
1. Client sends CONNECT 192.0.2.0:443
2. Server reads the following ClientHello from the client and searches for SNI
   server name.
3. Server connects to 192.0.2.0:443, sending the SNI server name if any.
4. Server retrieves certificates from 192.0.2.0:443.
5. Server generates a certificate based on the 192.0.2.0:443 certificate.
6. Server finishes handshake with client.
7. Client sends the actual request, encrypted.
8. Server reuses the connection to 192.0.2.0:443 and performs the request. It
   then writes the response back to the client.

This new approach may introduce slightly more delay since the client TLS
handshake is now completed when the server established a TLS connection with the
requested server. Previously the client could start sending data immediately
after sending the CONNECT line to WS.

Currently, the Subject field and subjectAlternateNames fields are copied from
the original certificate, disregarding the requested host name or IP address.
If the client gets a warning because of a domain name mismatch when connecting
directly, it will now also get that warning when connecting via WS. (It also
means that the above Android client does not complain about the names anymore.)

For that Android client, WS will still use the IP address in the logs though.
(WS cannot know which host name the Android client is comparing to.)
Debug log certificate from server