Implement save_single_paths option for Pathfinder

[amas0]

Submission Checklist

• Run unit tests
• Declare copyright holder and open-source license: see below

Summary

Intends to resolve #770.

Adds a save_singe_paths boolean keyword argument to CmdStanModel.pathfinder, which sets save_single_paths=True in the PathfinderArgs (this argument already existed). Also, exposes these output file locations to the user as part of the RunSet. Specifically, this adds two properties: RunSet.single_path_csv_files and RunSet.single_path_json_files that will only be populated with file paths if pathfinder is run with the new flag enabled.

This PR also changes slightly the cmdstanpy behavior for Pathfinder, specifically it explicitly defaults the num_paths argument to 4 within cmdstanpy. Previously, it defaulted to None and cmdstan under the hood would default to 4 paths. This meant (as far as I could tell) that cmdstanpy didn't have any explicit reference to the num_paths value if run using defaults.

Some follow-on questions I have:

• Right now, the file paths are accessible within the RunSet but no higher. Is there a desire to expose these files as properties on the CmdStanPathfinder class?
• Relatedly, is there any desire to load these files in, in some way like via a possible CmdStanPathfinder.single_path_draws() or something?

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): myself

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

• Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)

[WardBrian]

Your two questions are part of why we did not implement this when first exposing pathfinder -- it's not entirely clear when users want these, and it introduces a whole ton of conditional logic into the pathfinder return and the runset. I'm still not entirely convinced it's a good idea

[amas0]

Yeah, and my intuition is that there's not a real need to have it bubble up to the stanfit object.

I think it makes sense to include it in the runset, we do state in the docstring:

    Encapsulates the configuration and results of a call to any CmdStan
    inference method. Records the method return code and locations of
    all console, error, and output files.

It'd be a larger lift to do any processing of the resultant files, but storing a reference isn't too bad.