Easy parameter history access: priority for acheived or planned values

[arthursloan]

As part of PR #18 I made some initial QoL improvements for how data within the planning request can be accessed within a planner, namely adding an achieved_values and planned_values property to each parameter object so a user doesn't have to manually iterate through the list of parameter history objects stored in param_history. I'd like to add 2 capabilities to continue this:

1. The ability to just get all of the parameter and results history as one table, either as a list of lists, pd array, etc.
2. The ability to get a dictionary of the most recent condition and the result for planners in case the planners track their state outside of PyAres.

Both of these raise the question of how to handle the planned vs achieved values. Right now my thinking is that we use an "achieved priority" approach, where an achieved value is reported over the planned value if it exists. This seems the most consistent approach based on the requirement within ARES OS that the user has to specify that a parameter uses an achieved value, but I wanted to get other people's read on things. @nkleiner @rwaelder Let me know what you think about this approach.

[nkleiner]

Okay, so if it isn't already obvious I've gone on a bit of a blitz to resolve some of the PyAres issues you've posted that I've unfortunately been forced to neglect, and I saved this one for last because it was the only one I don't know the direction of yet.

I think having data be more easily accessible is an obvious win, but the question is who is making this data accessible and in what scope. If I'm reading into your comment here correctly it sounds like you're suggesting the planner service be given some extension methods that just dumps the data into some specific format that is more pythonic in nature and the user can do whatever they please with it (this would cover both of the two cases you mention here, obviously with slightly different extension methods).

As far as the question of planned vs achieved values, if we want to prioritize one over the other I'm not totally against that, but I'm also of the opinion that if we have both fields (regardless of whether both are populated as we don't force the user to link an achieved value to a planned value in ARES) then we might as well just provide both. I think this is better for transparency as wrapping which data is exposed in a setting and leaving a default like "Only give achieved" seems like it could cause headaches for someone newer to the library. My suggestion would be that if we want to give the option to only output one value (planned vs achieved), then we add that as a setting that defaults to both being provided. This means that a user forgetting to specify wouldn't lose any critical data, but if they're more savvy and know for certain they only care about achieved values, they can specify in the helper method call "I only want achieved values in my data output" and they'll get exactly that

[rwaelder]

Chiming in on the achieved vs. planned conversation:

I think the scientist is interested in an "achieved priority" mentality regardless of how the data is presented. The problem is that we have cases where the achieved value is empty, so for processing data after the fact, it is then up to the module designer to reconcile those data columns.

My suggestion is to either provide one or three columns. Either you just want the mixed data with achieved priority, or you also want the raw data, maintaining access to the achieved value priority data.

For implementation, I don't really care if that looks like getting the combined column by default and a flag gets you the raw columns, or if you just get all three by default. Labeling schema could be something like "val, val_achieved, val_planned"