Improve RTI classloader management

[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 three 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. Since it's impossible to remove paths from a classloader, switching RTI providers at runtime doesn't work because though you can add new paths, the classloader will still find the old ones first.

3. 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 relatively non-complex solution to these issues is as follows:

• On the FIRST startup, we store the current thread's context class loader, to use as a base
  for extension (and to avoid daisy-chaining extended loaders).

• We maintain a map, initially empty, associating RTI providers with extended classloaders.

• On ANY startup, we retrieve or create a child classloader under the original stored one,
  extend it with the paths for the configured RTI provider, and set it as the current thread's
  classloader.

• On ANY attempt to load an RtiFactory, we use the most recent extended classloader.

This effectively ensures that:

1. RtiFactory implementations are always available, irrespective of which thread the factory
   method is called from.

2. Implementation classes from different RTI providers never conflict.

3. Native libraries are always loaded using the same classloader.

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, so the call is effectively redundant.