Add metadata with some defaults

[jdkio]

Adds metadata (note the fiducial volume numbers reflect what's in main right now, so they'll update if that changed in the new PR):

root [1] Metadata->Show(0)
======> EVENT:0
 DuneTMSVersionMajor = 1
 DuneTMSVersionMinor = 0
 DuneTMSVersionPatch = 0
 GeometryGitTag  = v2025.08.11
 GeometryGitBranch = HEAD
 GeometryGitCommit = cc28d73d93ee4c50c9f5b453c996e4ea20373e2f
 NumberOfScintillatorPlanes = 82
 NumberOfSteelPlatesThin = 34
 NumberOfSteelPlatesThick = 22
 NumberOfSteelPlatesDouble = 24
 TMSFiducialStartX = -3300
 TMSFiducialStartY = -2850
 TMSFiducialStartZ = 11362
 TMSFiducialEndX = 3300
 TMSFiducialEndY = 160
 TMSFiducialEndZ = 18314

The plan was to use aux data from the geometry but it really doesn't seem to make it all the way into the edep sim root file. The processing I use to access the B-field would return a null pointer at least for the world vol. So I put them in the config file instead

[AsaNehm]

Looks good to me. Would wait for merging for Lukas though

[ast0815]

Are you sure you want to keep all of these things updated by hand? Are you sure people will always update these things when running on an updated geometry? I fear it would do more harm than good if you store a geometry version number in the output that is actually not the geometry you used. Or maybe someone in the future will think that this configuration chooses the geometry. So they think they are now running with an updated geometry rather than whatever is in the file they are running on.

If this is about just keeping track of what geometry was used, should that not be handled by the upstream edepsim step and the general "provenance tracking" of the processing framework?

If this is about keeping track of what version of the algorithm is run, should that not store the tag or commit of DUNE-TMS rather than the geometry file? This should then probably be automatic, i.e. something that is read out from git itself when the code is built. Since (at least currently) the expected geometry is kinda hard coded anyway, this would, in a sense, also give you information about the kind of geometry that it was run on.

If the current tags in the world volume do not make it through, that is something that should be fixed in edepsim or dunendggd, e.g. maybe it does work when you put the meta data into a different volume? Or edepsim needs to be patched to store all aux variables. I get the desire for a quick fix, but temporary solutions have a tendency to become permanent.