Adding TLS_FALLBACK_SCSV support

This is an attempt to upstream changes made in Android
for POODLE. I have tried to be more sympathetic here to APIs
and make it optional.

This is early / incomplete, but I'm sending it out for feedback in
case you get a chance to look before Monday.
> any reason to not make this true always?

Because I didn't want to modify OkHttp's default behavior or take on changing the tests as part of this change. As above.

Android will set it to be on. I would be happy if it was always on, though (though I'd like to delay until we've improved the fallback steps / attempts to only make requests that are compatible with the ConnectionSpec).

As mentioned in the TODO below I was toying with making "I wish to have TLS_FALLBACK_SCSV on" combined with a socket factory that doesn't support an error (i.e. "you've asked for X but you're not getting X! Don't think you're safe!"). Android could only turn it on if the socket factory supports it. I also assume that OpenJDK and so on may not support this cipher value.

Also, in case it's not clear, the TLS_FALLBACK_SCSV change basically means that when connecting to a modern server we expect all connection fallbacks to fail. Any compliant server that sees the this SCSV will reject the attempt to handshake. We can expect some (small, I hope) proportion of connection attempt that previously succeeded to fail as a result of this. Old servers that don't recognize TLS_FALLBACK_SCSV will ignore it.

Something that I haven't addressed on Android is that there is no obvious way to tell that a handshake failed _because of_ TLS_FALLBACK_SCSV. This means that the first connection fallback will fail (implying all subsequent fallbacks will also fail). Then it does them anyway! Not particularly efficient.

All this is somewhat misleading in the logs because the original handshake error from the initial attempt is being lost and the user sees the final attempt thrown. Ideally I'd like it to be kept (suppressed / cause exception?) or logged somehow.

> If it's true always, we can just include it in the default cipher suites offered by COMPATIBLE_TLS

Not convinced we can.

The presence of the TLS_FALLBACK_SCSV is only meant to be there if it truly is a fallback attempt. I can construct a client that uses COMPATIBLE_TLS without first trying MODERN_TLS, can't I? It should not then include the TLS_FALLBACK_SCSV.

This is why I try to track whether the connection attempt is a fallback. The Android code after the various TLS_FALLBACK_SCSV and 3/4 stage fallback possibly makes this a bit clearer. I'm going to look at the fallback after we've agreed this.