Memory leak in create_detector(...) (ForwardRomanPot_geo.cpp:128)

### Environment: (where does this bug occur, have you tried other environments)
- Which branch (`main` for latest released): main
- Which revision (`HEAD` for the most recent): HEAD
- Any specific OS or system where the issue occurs? CI

### Steps to reproduce: (give a step by step account of how to trigger the bug)
- https://github.com/eic/EICrecon/actions/runs/3795776388
- [valgrind-memcheck-eicrecon-pi-arches.log](https://github.com/eic/EICrecon/suites/10089004319/artifacts/491667626)

### Expected Result: (what do you expect when you execute the steps above)
No memory leaks.

### Actual Result: (what do you get when you execute the steps above)
Memory leaks reported in `ForwardRomanPot_geo.cpp:122` and `ForwardRomanPot_geo.cpp:128`:
```
==46== 14,959 (360 direct, 14,599 indirect) bytes in 1 blocks are definitely lost in loss record 16,510 of 17,314
==46== at 0x4840F2F: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==46== by 0x5CC4331: dd4hep::DetElement::DetElement(dd4hep::DetElement, std::__cxx11::basic_string, std::allocator > const&, int) (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCore.so.1.23)
==46== by 0x2AE87C09: create_detector(dd4hep::Detector&, dd4hep::xml::Handle_t, dd4hep::SensitiveDetector) (ForwardRomanPot_geo.cpp:122)
==46== by 0x2AE89209: create (ForwardRomanPot_geo.cpp:200)
==46== by 0x2AE89209: (anonymous namespace)::Factory*)>::call(dd4hep::Detector*, dd4hep::xml::Handle_t*, dd4hep::Handle*) (Factories.h:242)
==46== by 0x2A961250: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A9619D9: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963E23: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963EB7: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963EB7: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A965554: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46==
==46== 14,959 (72 direct, 14,887 indirect) bytes in 1 blocks are definitely lost in loss record 16,511 of 17,314
==46== at 0x4840F2F: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==46== by 0x5CBCE20: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCore.so.1.23)
==46== by 0x5CC088F: dd4hep::DetElement::add(dd4hep::DetElement) (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCore.so.1.23)
==46== by 0x5CC4382: dd4hep::DetElement::DetElement(dd4hep::DetElement, std::__cxx11::basic_string, std::allocator > const&, int) (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCore.so.1.23)
==46== by 0x2AE87C09: create_detector(dd4hep::Detector&, dd4hep::xml::Handle_t, dd4hep::SensitiveDetector) (ForwardRomanPot_geo.cpp:122)
==46== by 0x2AE89209: create (ForwardRomanPot_geo.cpp:200)
==46== by 0x2AE89209: (anonymous namespace)::Factory*)>::call(dd4hep::Detector*, dd4hep::xml::Handle_t*, dd4hep::Handle*) (Factories.h:242)
==46== by 0x2A961250: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A9619D9: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963E23: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963EB7: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46==
==46== 15,007 (360 direct, 14,647 indirect) bytes in 1 blocks are definitely lost in loss record 16,512 of 17,314
==46== at 0x4840F2F: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==46== by 0x5CC4331: dd4hep::DetElement::DetElement(dd4hep::DetElement, std::__cxx11::basic_string, std::allocator > const&, int) (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCore.so.1.23)
==46== by 0x2AE87D85: create_detector(dd4hep::Detector&, dd4hep::xml::Handle_t, dd4hep::SensitiveDetector) (ForwardRomanPot_geo.cpp:128)
==46== by 0x2AE89209: create (ForwardRomanPot_geo.cpp:200)
==46== by 0x2AE89209: (anonymous namespace)::Factory*)>::call(dd4hep::Detector*, dd4hep::xml::Handle_t*, dd4hep::Handle*) (Factories.h:242)
==46== by 0x2A961250: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A9619D9: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963E23: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963EB7: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A964E92: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A963EB7: dd4hep::Converter::operator()(dd4hep::xml::Handle_t) const (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
==46== by 0x2A965554: ??? (in /opt/software/linux-debian-x86_64/gcc-12.2.0/dd4hep-1.23-ph45g3a6oufv5uasmgt6jgufpxrvuzcj/lib/libDDCorePlugins.so.1.23)
```

### Additional context
The second case is clearest:
```cpp
for (size_t ic = 0; ic < sensVols.size(); ++ic) {
PlacedVolume sens_pv = sensVols[ic];
DetElement comp_de(mod_de, std::string("de_") + sens_pv.volume().name(), ic + 1);
comp_de.setPlacement(sens_pv);
}
```
where `sens_pv` is a _copy_ of `sensVols[ic]`, and all these temporary are cleaned up when going out of scope, but because DD4hep does reference counting of handles there remain some resources allocated.

In any case, this memory leak is just a symptom of a pattern that is unlikely to be functional.