JERSEY-2205: Jersey client - The ClientAsyncExecutorsFactory hosts thread pools that are not shut down when the hosting client is shut down.

When a `JerseyClient` that was using asynchronous requests in the past is closed via `Client#close()` shortly before the exit point of a Java program, this program will not exit for a couple of seconds (unless `System.exit(int)` is called explicitly).

When looking at the thread dump of the application, I found that there were several alive threads named *jersey-client-async-executor-x* which were in a waiting state even after I shut the client down. Tracing this, I found that the `ClientAsyncExecutorsFactory` is hosting two `ExecutorServices` where the `requestingExecutor` represents an actual thread pool. This thread pool is not shut down explicitly, even though the hosting `ClientRuntime` was closed. As a result, the JVM cannot exit before the threads have expired what takes up to 60 seconds. I created a small patch that closes the underlying `ExecutorService` and my application did not longer exit wit this delay.

I therefore suggest to add a method `ExecutorsFactory#shutdown()` which can be invoked by the `ClientRuntime` when the latter is closed in order to avoid this transitory thread leak. I suggest making this method a part of the `ExecutorsFactory`'s contract for consistency reasons even though it is only required for the `ClientRuntime` since the `ServerRuntime` is not explicitly shut down.

I created an [issue](https://java.net/jira/browse/JERSEY-2205) to this pull request and signed the Oracle contributor agreement. However, it is hard to provide a unit test covering this issue. It is however easy to see from the code that the executor service is never explicitly shut down in the current version. From the javadocs:

> An unused ExecutorService should be shut down to allow reclamation of its resources.

**Note**: I was not able to build the project. I got numerous test case failures even without my patch.