It's more likely that the property is a PropertyWithValue<double> or
TimeSeriesProperty<double>, so put these first rather than trying all
the PropertyWithValue types before moving on to the TimeSeriesProperties.

(This has no significant effect on the performance tests)

re #17197

If value has already been found, cache it in case we need it again

Results of performance test locally (Win7 Debug):
before 1.56 s
after 0.09 s

re #17197

Test exceptions in both cases:
- string cannot be parsed
- not a numeric value or a string

Also add spaces to exception string.

re #17087

Median was missing, and Mean was implemented as TimeAveragedMean:
correct this and implement all members of the enum.

re #17087

(Strings that can be parsed as a number)

re #17087

re #17087

Tries double, int32_t, int64_t, float, uint32_t, uint64_t

re #17087

re #15289

in all cases call getProtonCharge to get the proton charge
re #14323

This fixes the regression test. We clear the logs off the temporary workspace, that way we don't have to do a similar thing in the loop, and we avoid copying them over each time. This is not a fully formed solution, but it's a start.

Refs #9059

Catch the exception if the contents of the run_start or start_time
properties cannot be turned into a valid DateAndTime. Turn it into the
exception for a generic failure of this method.

Takes all TimeSeriesProperty logs and clears out all entries
except the last one. Single value logs are left unchanged.

tests show that.