The test contains a cookie jar file where one of the cookies has an
expiry date of 1391252187 -- Sat, 1 Feb 2014 10:56:27 GMT which has
now expired. Updated to Wed, 14 Oct 2037 16:36:33 GMT as per test
179.

Reported-by: Adam Sampson
Bug: http://curl.haxx.se/bug/view.cgi?id=1330

In preparation for adding URL specific options moved the initialisation
of the Configurable structure into a separate function in tool_cfgable.

Since the timer resolution is lower, there are actually cases that
the compared values are equal. Therefore we check for previous
timestamps being greater than the current one instead.

Since the output isn't actually being written in text-mode and it
was rather used as a workaround, disable text-mode for these tests.

According to section 2.2 of RFC959 the End-of-Line is defined as:
 The end-of-line sequence defines the separation of printing
 lines.  The sequence is Carriage Return, followed by Line Feed.

Verified by sniffing traffic between a Windows FTP client (FileZilla)
and Unix-hosted FTP server (ProFTPD).

It makes more sense to convert the expected output to [CR][LF] on
Windows than to force the actual, probably correct, output to [LF].

This way it is actually possible to see if curl outputs the correct
line-ending excepted by a text-aware test case.

For some reason Windows 7 SP1 chooses TLS 1.0 instead of TLS 1.2
if it is not explicitly enabled within grbitEnabledProtocols.

More information can be found on MSDN:
http://msdn.microsoft.com/library/windows/desktop/aa379810.aspx

The minor version will be dropped for HTTP 2 so it will make sense to
avoid using it in option names etc.

... and then go through the "normal" HTTP engine.

Check the NPN result before preparing an HTTP request and switch into
HTTP/2.0 mode if necessary. This is a work in progress, the actual code
to prepare and send the request using nghttp2 is still missing from
Curl_http2_send_request().

To better reflect its purpose

NPN is what is available in the wild today to negotiate SPDY or HTTP/2.0
connections. It is expected to be replaced by ALPN in the future. If
HTTP/2.0 is negotiated, this is indicated for the entire connection and
http.c is expected to initialize itself for HTTP/2.0 instead of
HTTP/1.1.

see:
http://technotes.googlecode.com/git/nextprotoneg.html
http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-04

This makes it easier to trace what's happening.