[OPENJPA-2962] Do not create a broker to obtain a class loader

[rzo1]

The four schema management methods each built a Broker through newBrokerImpl() only to call getClassLoader() on it. That loader was always null: BrokerImpl assigns it in initialize(), which newBrokerImpl() never reaches, so the broker was asked a question it structurally could not answer and then dropped.

They now pass the thread context class loader, which is the value initialize() would have assigned, and which postCreationCallback() already passes for the same synchronizeMappings() calls.

Closing the broker instead was not available: close() runs free(), which dereferences a cache an uninitialized broker has not got, so a finally { broker.close(); } would have turned four working methods into four that throw. Nothing heavyweight leaked either — without initialize() there is no store manager, no connection and no registration with the factory; the cost was a finalizable object per call whose finalizer threw and was discarded.

The only behaviour that changes is that a class loader now reaches MappingTool, so a custom openjpa.Sequence class resolves where it previously fell back to the bootstrap loader.

Routing through getClassResolverInstance() was considered and rejected: where OpenJPA's own loader differs from the context loader it returns a MultiClassLoader that is then re-resolved downstream against a different context class, producing a nesting an initialized broker would never produce.

The ticket also names dropPersistenceStrucuture and validatePersistenceStruture; cbb19f7 has since corrected both spellings.