Is your feature request related to a problem? Please describe.

When solving mathematical programs, we offer users the ability to provide a SolverOptions object that customizes various tuning and debugging parameters. A typical use would be turning on debug printing, or adjusting a certain kind of solve tolerance to be looser or tighter, or setting a cap on the max number of iterations / steps.

The options are conceptually a list of tuples, typed as (solver_id : SovlerId, option_name : str, option_value : Union[float,int,str]) that disallows duplicates of the same (solver_id, option_name). The API to access the data implements this as as a map of maps (keyed on solver_id and then option_name).

At the moment, the only way that users can set these options is by calling solver_options.SetOption(...). when the user has a set of typical options they would like to use, they currently need to consolidate that set into a piece of common code (i.e., a helper function). This ends up being klunky, at scale.

There is also no structured way to "dump" the list of options for offline inspection. There is a to_string feature but it's intended for console debugging, and so is not well-structured.

Describe the solution you'd like

Add the Serialize() capability to SolverOptions, so that (like other pure-data classes in Drake) they can be loaded from JSON and YAML, and dumped to JSON and YAML.

Describe alternatives you've considered

None.

Additional context

This will probably involve changing/deprecating some of the API that SolverInterface implementations use to access the data, but hopefully will not deprecate an user-facing API for setting up their programs. The goal is to offer more capability to users, hopefully without disrupting anything.

This also means that we're going to need to make the SolverId::name() result become a load-bearing part of our Stable API. We'll be saving the solver names in the JSON/YAML, so they need to become a durable promise. We might need to change up some of the names before stabilizing them.

This will also require formulating a solver "name" for Drake's "common" solver options, along with conventional string names for each of the options.