Make History Information Accessable and Usable

As it has come up repeatedly, saqc does not really give the user possibilities to make use of its complex history/tracking mechanics. Currently only the dmp-comment field and the plot function do really profit from the history. Since a lot of work went into the implementation, and also ultimately the flags tracking is what makes saqc unique - i find this a pitty.

I also think, there are easy ways to enable flags tracking, without much extra work - what makes me feel it even more of a pity, that it isnt there:

1. Dont hide the history Object:

• Is there any reason, why we dont allow any history-accessor, like, returning a dataframe, upon, for example qc.history[field]? This would at least allow a user to construct a history-sensible pipeline by manually inspecting the history and reinstantiating saqc objects.

2. Allow keyword based labeling.

• As it works with the plot-label workflow, I think it can be futile to allow the option to associate history columns with user defined IDs. By this, the following work flows can be easily implemented:

• Make isFlagged sensible for the ID, so that flagGeneric can be passed logical conditions based on variables and tests. This enables a lot flagging workflows that may appear too complex for saqc on first sight, because it allows for more complex logical dependencies, and a lot of flagging worflows is of the type: "Flag this, if testX did that and testY did this". So it would look like:

qc.flagFuncY(field,parameters,id='testY')
qc.flagFuncX(field,parameters,id='testX')
qc.flagGeneric(field, field1, func=lambda x: isflagged(field, 'testY') & isflagged(field, 'testX'))

• Basically any function that does history-sensible operations (such as the flags Repeater) can be easily implemented and used in a syntactical atomic way, by allowing it evaluation of the ID keyword.

qc = qc.flagRange(field, min=-10, ID='min_test')
qc = qc.flagAfter(field, '3H', 'min_test')

Since we wont be able to work extensively on saqc development in the near future, i feel even more that this things should be considered to bring in soon, since it are options, both feasable in implementation effort and futile in tracking enabling.