Use common classloader for all RTI factory calls

[isaiahhaensel]

In HLA mode (RPR connection), Disco relies on extending the classpath with RTI provider libraries and uses an implementation of RtiFactoryFactory which employs the current thread's context class loader.

This currently contributes to two issues:

1. Only the context class loader of the thread that calls OpsCenter#open benefits from the classpath extension, so any calls to RtiFactoryFactory#getRtiFactory from other threads (e.g., worker threads calling FederateAmbassador#receiveInteraction) may fail.

2. RTI providers (e.g., MAK) may use native libraries that cannot be loaded in more than one classloader. This means that if DisApplication#start is initially called from one thread, then later from another thread, the second call will fail on RprConnection#initializeFederation's call to RtiFactoryFactory#getRtiFactory. See below for an example error when using the MAK RTI.

ERROR: hla.rti1516e.RtiFactory: Provider com.mak.makrti1516e.DtRtiFactory could not be instantiated
...
Caused by: java.lang.UnsatisfiedLinkError: Native Library C:\MAK\makRti5.0.1\bin\makRtiJava1516e64.dll already loaded in another classloader

A simple way to resolve this is to ensure that all RtiFactory loading attempts use the same classloader. This PR achieves this by adding a new RprRtiFactoryFactory class which caches the classloader on the first call and re-uses it for all subsequent calls.

Additionally, and only indirectly related, this PR adds a check to avoid calling RtiAmbassador#destroyFederationExecution when disconnecting from a MAK RTI federation, because (at least currently) that call frequently either hangs, crashes the application, or crashes the JVM with an EXCEPTION_ACCESS_VIOLATION at librti1516eJava64.dll+0xc0525. The MAK RTI is designed to clean up the federation execution on disconnect anyway, making the call effectively redundant.