Better handling of MicroProfile Rest Client Proxies

[Pandrex247]

The MicroProfile Rest Client API asks a user to provide just a hostname and a port.
When this is provided to the various connectors which support proxy configuration via ClientProperties.PROXY_URI they will fail to translate this if something simple such as localhost:8765 is provided (as the MicroProfile Rest Client TCK does).

https://github.com/eclipse-ee4j/jersey/blob/master/connectors/apache-connector/src/main/java/org/glassfish/jersey/apache/connector/ApacheConnector.java#L281

final URI u = getProxyUri(proxyUri);
final HttpHost proxy = new HttpHost(u.getHost(), u.getPort(), u.getScheme());

...

private static URI getProxyUri(final Object proxy) {
    if (proxy instanceof URI) {
        return (URI) proxy;     }
    else if (proxy instanceof String) {
        return URI.create((String) proxy);
    } else {
        throw new ProcessingException(LocalizationMessages.WRONG_PROXY_URI_TYPE(ClientProperties.PROXY_URI));
    }
}

This is because they attempt to convert the given string to a URI and then parse details from it using URI methods. So a proxy config from MicroProfile Rest Client of localhost:8765 would at the moment be given as-is, and when converted to a URI will result in the host being null and the scheme being set to localhost, leading to an error further down the line.

This change attempts to resolve this by simply defaulting to HTTP if no schema is given by essentially doing the same check as the connectors earlier on, resulting in the same string from MicroProfile Rest Client becoming http://localhost:8765. I've tried to account for IP addresses as well as host names (since the MicroProfile spec says to support them), but yell if I've missed an acceptable URI format.

Tested on Jersey 2.34 using MicroProfile Rest Client 2.0 TCK with Apache HTTP Client connector (since default Jersey connector doesn't support proxy config in this manner). Not current master or latest 3.0 of MicroProfile Rest Client, but just from eyeballing it none of these bits of code seem to have changed.