Comprehensive way to manage ReSolve configuration parameters

[pelesh]

ReSolve includes several different linear solvers and supports three hardware backends. There is a large number of parameters in ReSolve to select specific solution strategy and to tune its performance. Many of the parameters are specific to a specific solver type or hardware backend or both. We need a hierarchical method to allow user to configure ReSolve easily without sifting through dozens of (often cryptically described) parameters. Most of these parameters need to be set at runtime.

This issue is to start discussion how to handle this most effectively.

The issue originally raised by @kswirydo in #86 (comment)_

[pelesh]

Another part of this discussion is how to implement interface to ReSolve's select-from-the-list options. Currently we are just passing strings as this is quick'n'dirty way to set those options and get everything running. Perhaps a better way is to expose those lists to users in a form of enums. This will require some thinking about the scope in which these enums will live.

See how we handled similar issue in #12.

Also suggested by @kswirydo in #86 (comment)_

[stonecoldhughes]

has this utility been tested for all input conditions? Is there logic to detect and report ill-formed combinations of options?

Config options are often represented naturally with a hierarchical data format, and this allows them to be saved for later use. Does that capability exist with this parser? If not, is it desirable?

https://github.com/nlohmann/json is a single header file, so it could be added to the repo once and never bothered with again.

https://github.com/nlohmann/json can parse JSON from a file or the command line directly via stdin if file I/O is undesirable.

Thousands of users have helped refine json.hpp, it is extremely robust and extensively tested.

[stonecoldhughes]

For compile-time options, it looks like CMakePresets is being used, which is definitely the best way to organize repeatable build configurations with CMake

[cameronrutherford]

has this utility been tested for all input conditions? Is there logic to detect and report ill-formed combinations of options?

Config options are often represented naturally with a hierarchical data format, and this allows them to be saved for later use. Does that capability exist with this parser? If not, is it desirable?

https://github.com/nlohmann/json is a single header file, so it could be added to the repo once and never bothered with again.

https://github.com/nlohmann/json can parse JSON from a file or the command line directly via stdin if file I/O is undesirable.

Thousands of users have helped refine json.hpp, it is extremely robust and extensively tested.

Storing Re::Solve runtime options as JSON seems like a reasonable enough option to me.

We have used TOML files for another project to some success for storing arrays of test cases with sane defaults. Doing this in JSON might be a little harder.

Maybe we can do a mix of TOML for testing, and JSON for runtime options?