Add sample metadata to store information not already in updated.yaml

[JesusTorrado]

Information that could be stored (in general, stuff about the chains themselves that is not already in the updated.yaml):

• whether burn-in has been removed
• whether the sample has been thinned
• whether the sample has been cooled down
• the sample temperature? (I guess not, since it's actually part of the sampler updated.yaml block?)

How to store that? A few alternatives:

• Another block (analysis?) in the updated.yaml
• Another file (could be GetDist's properties.ini)

[cmbant]

Related to this is the annoying code duplication between getdist and cobaya, e.g. to get the ranges have to parse the parameter blocks. Potentially this could be part of metadata too.

[JesusTorrado]

The code duplication is there in order not to need to have Cobaya installed to read chains with GetDist. I don't think it will be cured by adding more stuff to the metadata, since then we would be duplicating two things: (a) the metadata parser (we will also need it in Cobaya to load chains as Collections), and (b) the data themselves (not only ranges, but also labels, and possibly more).

From the user point of view, I would rather duplicate code (which as a user I don't see) than data (which as a user looks chaotic: which is the one I should trust / write my own parser for?).

[JesusTorrado]

NB, as a reminder for myself: when we add the metadata, we should load the temperature from it, as opposed to from the samples as it is done right now.

[cmbant]

There probably isn't a very compelling reason for getdist not to just use cobaya when loading cobaya chains.

[cmbant]

Note grid scripts 326 currently use .properties.ini to store burn-removed info a la getdist.