ScriptedConfiguration.release() leaves the published engine's customizer class registered, pinning one GroovyClassLoader per release #154

ScriptedConfiguration.release() drops the published engine but never unregisters the class of its customizer script. The REST, CREST and SSH configurations register an ExpandoMetaClass on that class in createCustomizerScript (customizerClass.metaClass.customize << {…}: ScriptedRESTConfiguration.groovy:189, ScriptedCRESTConfiguration.groovy:224, SSHConfiguration.groovy:387). On Groovy 2.4.21 a registered metaclass stays reachable from the global ClassInfo set, so it keeps the customizer class alive, and with it:

• the configuration's own GroovyClassLoader and every script it compiled (ScriptedConfiguration.getGroovyScriptEngine() builds a new loader per configuration);
• the released configuration itself, which is the owner of the customize closure.

Every facade dispose or configuration change of a REST, CREST or SSH connector therefore leaks one loader. A probe of 50 attempts in the review of #132 found every such loader alive after heap exhaustion, and none when no metaclass was registered.

#132 fixes the same pin for a customizer that fails (InvokerHelper.removeClass in initializeCustomizer()'s catch), because a retry compiles a new class each time. The class of a customizer that succeeded is not covered; the code on master behaves the same.

Proposed fix (from the #132 review): initializeCustomizer() returns the customizer class; getGroovyScriptEngine() keeps it in a field guarded by the configuration's monitor next to the published engine; release() calls InvokerHelper.removeClass on it after the release closure has run, then clears the field.

Test: the stand-in from ScriptedConfigurationTest.testFailedCustomizerClassIsUnregistered with a customizer that succeeds, then configuration.release(), then ClassInfo.getClassInfo(clazz).getStrongMetaClass() is null. It fails without the release() change.

Raised in the review of #132 (#132 (review)).