FactoryFinder.find should not solely use the contextClassloader of the current thread

We are using jaxrs/jersey in a tomcat webapplication.
Wihtin this webapplication we additionally use an osgi runtime (felix) for plugins.

Now we have a problem when somebody uses jaxrs/jersey inside the osgi bundle.

This is what happens:

* we have jersey in tomcat and another jersey inside the bundle
* Inside the osgi bundle we want to use```
ClientBuilder.newClient()
```

to get a client

* this calls FactoryFinder.find() which uses the contextClassloader of the current Thread to laod the class
* since the Thread is created outside the bundle this leads to the catch block [https://github.com/jax-rs/api/blame/9c5b403aa537ceea7ddd33533c00f6ff83f6e4ef/jaxrs-api/src/main/java/javax/ws/rs/client/ClientBuilder.java#L90](https://github.com/jax-rs/api/blame/9c5b403aa537ceea7ddd33533c00f6ff83f6e4ef/jaxrs-api/src/main/java/javax/ws/rs/client/ClientBuilder.java#L90)```
java.lang.LinkageError: ClassCastException: attempting to cast ...
```

Why is this fixed to the contextClassloader?
Classloader should be an optional parameter or the default should be to use the FactoryFinder Classloader and use contextClassloader as Fallback

Start with FactoryFinder.find() and the ClientBuilder.java code linked in the issue, then review how the thread context classloader is used when ClientBuilder.newClient() is called from an OSGi bundle. Reproduce the Tomcat/Felix classloading scenario and clarify the expected loader and fallback behavior; the issue does not name a regression test or establish a settled implementation.

Written by the indexing model from the issue text.