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.

the number of elements in the 'nghttp2_session_callbacks' structure is
now reduced by 2 in version 0.3.0 (I'm not sure when the change
happened, but checking for ver 0.3.0 work for me).

Something is wrong in 'userp' for the HTTP2 recv_callback().  The
session is created using bogus user-data; '&conn' and not 'conn'.

I noticed this since the socket-value in Curl_read_plain() was set to a
impossible high value.

Fixed two compiler nits