Modify the cipher suite / TLS version selection behavior

Work in progress. Sent for consideration.

Motivation 1: Opinionated cipher suite selection makes sense for
OkHttp when bundled with apps. OkHttp probably has the best/newest
information available when compared with the socket factory it
encounters.

However, with the Android platform usecase the socket factory (the
one from the platform, from GMS core or installed by the app) might
have better information (or reasons why specific suites should not be
used and so modifies the enabled set). Android would therefore prefer
OkHttp to use the default set.

Motivation 2: TLS protocol version selection is performed over
"supported" not "enabled" values. This will cause protocols that are
disabled by default to be re-enabled. Similar argument here as for
motivation 1: Android would like to avoid enabling protocols that
are considered unsafe and are disabled by the apps or GMS core.

----

This change includes the ability to select from "enabled" or
"supported" values for both sets, and introduces the ability to use
the default set of ciphers.

This change is probably overkill depending on whether you believe
that the supported Vs enabled behavior is a bug or a feature. With
this change Android can specify what it wants while retaining
existing OkHttp behavior. I am looking for guidance on what subset
you would be happy with.

When I understand what we want I can add a ConnectionSpec test.

The ConnectionSpec caching has been removed from ConnectionSpec.
This seems like an risky optimization to me in an environment where
different SocketFactory instances could be encountered and doing it
properly seems costly and of limited benefit.

In a later change I am also going to want to repeat an Android
change where we will not attempt a fallback connection if we know
it will not be valid (e.g. if none of the TLS versions or cipher
suites would be supported / enabled). It may make sense to postpone
the TLS version change until that is discussed. The decision about
whether a fallback can be attempted has to be made on the prior
connect attempt and so requires more extensive changes that may
modify the ConnectionSpec API.
Do we need this flexibility? Or should we always use the SSL socket's enabled set?