A race condition leads to failing resource-bundle registration during deactivation

The following exception was observed:

[sling-default-5-ResourceBundleProvider: reload all resource bundles] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of job 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, java.util.Dictionary)" because "this.bundleContext" is nulljava.lang.NullPointerException: Cannot invoke "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, java.util.Dictionary)" because "this.bundleContext" is null at  org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532) [org.apache.sling.i18n:2.6.2]

During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that are still running can try to register new resourceBundles. This fails, if deactivate already set bundleContext to null. 

Proposed solution:

• Simplify and improve the thread-safety model by encapsulating bundle service registration/deregistration and bookkeeping in the new class ResourceBundleRegistry.
• The thread-safety concerns related to registration, deregistration, bookkeeping of the resource bundles and of their associated service registrations are encapsulated in the new class. 
• The object is created in the activate method and closed in the deactivated method.
• The new class receives bundleContext in the constructor, removing the need for a field in JcrResourceBundleProvider.
• The isClosed state of the new class is used as a cancel flag during deactivation to prevent new registrations, processing of new onChange events and scheduling new bundle reloading jobs during deactivation.
• Add unit tests for interleaved registration, clearing, deactivation.