SOLR-18005 move to jetty package and rename

[dsmiley]

https://issues.apache.org/jira/browse/SOLR-18005

Moving jetty client stuff to the jetty package, that haven't yet moved there.
Renamed Http2SolrClient to HttpJettySolrClient.
CloudJettySolrClient added, and enhanced CloudHttp2SolrClient to detect if Jetty is available and to use that client if it is -- (same code here as provided in #3852)

Move CloudHttp2SolrClient.Builder to CloudSolrClient. There's now barely any references to CloudHttp2SolrClient. We'll probably remove that someday. I marked it as internal.

This'll be tough to review due to rename noise... I think it's boring honestly but the changes in the impl & jetty packages could be reviewed.

[epugh]

I scanned, and while I don't love the use of var, that is just me. The doc changes looked good. And the overall change looks good.

[dsmiley]

I added var systematically for HttpJettySolrClient (or via its Builder) for the case of calling a constructor to initialize it. So it's type is obvious, in theory, albeit I didn't look at every single line. Do you find the type unclear anywhere @epugh

[dsmiley]

FYI @jdyer1 ... even though HttpClusterStateProvider is exists in the apache package in the test framework, it will be removed, freeing up this name for use here.

[dsmiley]

needed occasional getters to expose things that are now in different packages and thus not exposed. A protected field on a builder isn't accessible to the class being constructed that uses the builder, if it's in another package.

[epugh]

I added var systematically for HttpJettySolrClient (or via its Builder) for the case of calling a constructor to initialize it. So it's type is obvious, in theory, albeit I didn't look at every single line. Do you find the type unclear anywhere @epugh

I think for me it's just a stylistic thing that twenty years of Java typing has leaned me against! In ruby it is all vars ;-)

[dsmiley]

I'm planning on merging this one late tonight or tomorrow morning.