Support customised service loader

[nicobrevin]

Description of Changes

As per #1382, adds a custom ServiceLoader#load method that supports customizing the classloader. In our case we have something of a plugin architecture that isolates the different plugins in their own class loader. This causes chaos and hilarity when the netcdf plugin is used, as it is not going to execute that code with the netcdf library's classloader set as the calling thread's context classloader. I have worked around it to some extent by finaggling our code to do a best-effort and forcibly load some of the offending netcdf classes with the context class loader set correctly, but that only works for the code that loads services in a static initializer.

PR Checklist

• Link to any issues that the PR addresses
• Add labels
• Open as a draft PR
  until ready for review
• Make sure GitHub tests pass
• Mark PR as "Ready for Review"

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[lesserwhirls]

It looks like switching out org.slf4j.LoggerFactory for ucar.nc2.util.log.LoggerFactorybroke compilation.

[nicobrevin]

Whoops, fixed. Also ran spotless, but all that did was remove some whitespace from my javadoc 🤷

If you think the change needs it, I can add tests, but I gave up quickly when I got errors about missing JDKs.

[lesserwhirls]

I would not worry about tests for this change, as our existing tests should cover these codepaths quite well. Spotless can be picky about things such as whitespace, which gets annoying. Thanks again for your contribution!

[lesserwhirls]

I think this approach will work nicely. Thank you so much for your contribution, @nicobrevin! Besides the compilation issue (see above) and the CLA, the only other thing that's tripping up the GitHub tests is the code style. To check the code style, you can run ./gradlew spotlessCheck, and to apply frixes you can run ./gradlew spotlessApply. Once the github tests pass, I'll run our full set of tests on our internal Jenkins just to be safe. At that point, we should be good to go and this would get in for the 5.10.0 release.

[nicobrevin]

Thank you so much for your contribution, @nicobrevin!

No worries at all, @lesserwhirls , I appreciate your timely response and pragmatism :)

[lesserwhirls]

Just a quick follow up that our internal tests also passed!

[lesserwhirls]

Just checking in to see if you've had a chance to review the CLA. I'm hoping to get a release out the door by the end of the week, or early next week at the latest, and would be happy to get this in.