Further results cache optimizations to support PowerAnalytics

[GabrielKS]

Two main things here:

1. load_results! was opening a store even if all the requested results were already cached; opening the store is now left to _read_results after it decides whether it needs to do so.
2. read_results_with_keys is slowish even if the results are already cached because a lot of data has to be converted to DataFrame. Now there is an optional kwarg to request a certain list of columns and only those will be converted, resulting in much (~1000x on large datasets) less memory usage and much faster call times.

The result is that load_results! and read_results_with_keys can be called thousands of times in a tight loop as PowerAnalytics iterates over components and it's not horrendously inefficient (just a few seconds total for large datasets). Leaving as draft in case I identify more small optimizations to add.

[daniel-thom]

Works for me. This is the first time I’ve heard about the use case of selecting individual columns.

[GabrielKS]

Works for me. This is the first time I’ve heard about the use case of selecting individual columns.

Yeah, this is due to the PowerAnalytics design decision to do things at the component level as much as possible, which lets a user define metrics solely on components and have the package take care of all the aggregation by ComponentSelector automatically. I made that decision very early on, before I realized results were so tied to the concrete subtypes, but so far with optimizations like these it hasn't proven inefficient enough to abandon — ignoring compile time I can run a compute call that fetches results for thousands of components of the same concrete type in about a second.