Fixing metadata retrieval from entries that contain chidren at TRestRun and TRestProcessRunner

[jgalan]

This PR is a patch to allow loading metadata objects and processes inside TRestRun and TRestProcessRunner that contain child elements, such as the recently added TRestAxionWolterOptics.

The problem was connected with the fact that the recently added InstantiateChildMetadata method requires access to the RML file. This problem could have been solved by implementing an additional LoadConfigFromBuffer that reads the input from configBuffer since that was available and with the proper contents.

However a quick solution for me was to pass the config filename to the additionally/new instantiated classes.

Please approve (I need the changes) and create and issue in case you find a better solution.

[jgalan]

I am getting the following compilation error on the GitHub pipeline

/__w/framework/framework/framework/source/libraries/track/src/TRestTrackLinearizationProcess.cxx: In member function 'void TRestTrackLinearizationProcess::GetHitsProjection(TRestVolumeHits*, const int&, TRestVolumeHits&)':
/__w/framework/framework/framework/source/libraries/track/src/TRestTrackLinearizationProcess.cxx:150:42: error: no matching function for call to 'TRestVolumeHits::GetX()'
  150 |         auto cl = GetBestNodes(hits->GetX(), hits->GetZ(), hits->GetEnergyVector(), nodes);

[jgalan]

Dont understand why it gets stuck here: https://gitlab.cern.ch/rest-for-physics/framework/-/jobs/23207995

Perhaps it is the python version?

[nkx111]

Dont understand why it gets stuck here: https://gitlab.cern.ch/rest-for-physics/framework/-/jobs/23207995

Perhaps it is the python version?

I created #264 to fix it. Looks like some infinite loop arises because of asymmetric brakets in the comment.