Support for system-configured HTTPS proxies.

*Back now with some additions and post-code-review revisions. Satisfies 
issue https://github.com/twitter/CocoaSPDY/issues/33*

By default, enables support for HTTPS proxies that can be configured
in the system settings either manually or with an auto-config URL. If
the proxy connection fails, the system settings must be removed to go
back to direct connection.

Three new configuration settings are exposed for the app's use:
enableProxy, proxyHost, and proxyPort. These can override the default
behavior.

An HTTP proxy, as configured in OSX and iOS at least, means it serves
HTTP requests and operates transparently without a CONNECT message.
An HTTPS proxy serves HTTPS requests and requires a CONNECT message.
It does not use a TLS session between the client and the proxy itself,
but will obviously proxy a TLS session between the client and
origin after the CONNECT exchange.

HTTP CONNECT support is a requirement, not because of TLS, but because
we'll be sending non-HTTP data through the pipe following the CONNECT.
Users of CocoaSPDY remain free to use either HTTP or HTTPS requests.
There is no support for configuring a proxy in either OSX or iOS that
uses TLS between the client and itself, which would serve to encrypt
even the CONNECT message.

Connecting to an origin no longer means we simply connect to the origin's
host/port pair. If there is a proxy in between, then the host/port is
different. A SPDYOriginEndpoint represents the actual network host/port
being connected to in order to reach the origin. Also, there may be more
than one proxy that needs to be tried, if the first one fails. This
implementation is geared towards that in the future, but only actually
supports a single proxy. This simplifies a lot of code and supports all
known use cases. There is no fallback from a failed proxy to a direct
connection. All of these are purely future work items if demand
dictates.

All interaction with Apple's proxy configuration APIs is encapsulated
in SPDYOriginManager, and is done in a way to facilitate unit testing.

Resolution of proxy auto-config URLs requires a runloop, so we will
schedule the provided runloop source on the current runloop, and let
the caller provide a completion block to run once resolution is done.
When no proxy auto-config URL is found, then the completion callback
happens immediately on the current thread.

The socket connect / disconnect call patterns had to change. Previously,
connectToOrigin could fail immediately and return an error. Now, it
will never fail, and instead will use the willDisconnectWithError
callback. The connect timeout now includes proxy connect time.
That's a question for @goaway but I'd guess yes, that's the reason. I'm just going for consistency here.