connectivity/source/drivers/jdbc/jdbc.component has

  environment="@CPPU_ENV@:affine"

to place the com.sun.star.comp.sdbc.JDBCDriver implementation into an affine UNOenvironment.

The com.sun.star.sdbcx.comp.hsqldb.Driver implementation (in the normal C++ UNO
environment), in ODriverDelegator::connect
(connectivity/source/drivers/hsqldb/HDriver.cxx), calls
StorageContainer::registerStorage to store an XStorage in a global map, then
calls the JDBCDriver (i.e., thread enters the affine environment), which calls
via (non-UNO) JNI into hsqldb.jar code, which in turn calls via (non-UNO) JNI
into Java_com_sun_star_sdbcx_comp_hsqldb_StorageFileAccess_isStreamElement
(connectivity/source/drivers/hsqldb/StorageFileAccess.cxx), which uses
StorageContainer::getRegisteredStorage to obtain the XStorage and use it.

But that XStorage is the original C++ object, not a proxy that witnesses the
mapping between the normal C++ and the affine UNO environment.  (And the thread
is still in the affine environment, after having passed through the Java stack
frames via non-UNO JNI.)

That does not necessarily cause any problems immediately (so apparently went
unnoticed for quite a while), but when the XStorage-implementation in turn wants
to obtain the SimpleLogRing singleton, it would now trigger the

  std::abort();//TODO

in cppuhelper/source/servicemanager.cxx (where the invocation-by-constructor
case hasn't yet been implemented for differing environments), when that
singleton is changed to use the constructor feature in
<https://gerrit.libreoffice.org/#/c/22020/> "tdf#74608: Constructor function for
SimpleLogRing singleton."

So just do any necessary mapping every time an XStorage stored in the static
StorageContainer is accessed.

Change-Id: I91a62fd7e1cec29026f70a2c3acdfe051885c0fa