Fix Python ownership transfer to LCIO containers

[jmcarcell]

BEGINRELEASENOTES

• Make Python-to-LCIO container ownership transfer automatic, fixing a crash when using the python bindings in LCG stacks

ENDRELEASENOTES

pyLCIO exposes the legacy LCIO ownership-transfer APIs directly through cppyy. LCCollectionVec::addElement(LCObject*) and LCEventImpl::addCollection(LCCollection*, ...) store raw pointers, but their Python proxies remain Python-owned. Python can therefore delete an object still referenced by an LCIO container.

The crash can be seen in the key4hep build workflow (https://github.com/iLCSoft/LCIO/actions/runs/34105308165/job/101688847377). I can reproduce it:

     *** Break *** segmentation violation
    
    
    
    ===========================================================
    There was a crash.
    This is the entire stack trace of all threads:
    ===========================================================
    #0  0x00007f32a73f334a in wait4 () from /lib64/libc.so.6
    #1  0x00007f32a7368383 in do_system () from /lib64/libc.so.6
    #2  0x00007f32a6388035 in TUnixSystem::StackTrace() () from /cvmfs/sft-nightlies.cern.ch/lcg/views/devkey-head/Mon/x86_64-el9-gcc16-opt/lib/cppyy/.././libCore.so
    #3  0x00007f32a67ae363 in (anonymous namespace)::TExceptionHandlerImp::HandleException(int) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/devkey-head/Mon/x86_64-el9-gcc16-opt/lib/cppyy/../libCPyCppyy.so
    #4  0x00007f32a6387301 in TUnixSystem::DispatchSignals(ESignals) () from /cvmfs/sft-nightlies.cern.ch/lcg/views/devkey-head/Mon/x86_64-el9-gcc16-opt/lib/cppyy/.././libCore.so
    #5  <signal handler called>
    #6  0x00007f32a68c10ac in __dynamic_cast () from /cvmfs/sft.cern.ch/lcg/releases/gcc/16.1.0-43042/x86_64-el9/lib64/libstdc++.so
    #7  0x00007f3282dfba35 in SIO::SIOSimTrackHitHandler::write (this=this
    entry=0x22246370, device=..., obj=<optimized out>) at /home/runner/work/LCIO/LCIO/lcio/src/cpp/src/SIO/SIOSimTrackHitHandler.cc:55

The crash is before the handler makes its first SIO call: it is the dynamic_cast of a dangling LCObject*. Retaining Python proxies lets writing complete but then crashes during CPyCppyy proxy destruction, confirming double ownership.

This looks likely to have been a long-standing ownership bug. The move of the nightlies to the LCG stacks likely exposed it through the current cppyy and Python 3.13 runtime.