Added SaveConfigCallback.save_config

[mauvilsa]

What does this PR do?

Makes it easy to subclass SaveConfigCallback to additionally save the config in other places, such as a logger. The main purpose of this feature is to provide a way to implement a custom save config without having to worry about ranks or race conditions.

Motivated by #15340 (comment)

Might fix #14628, unless we consider that to be an out-of-the-box saving as artifact in logger.

Before submitting

• Was this discussed/agreed via a GitHub issue? (not for typos and docs)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure your PR does only one thing, instead of bundling different changes together?
• Did you make sure to update the documentation with your changes? (if necessary)
• Did you write any new necessary tests? (not for typos and docs)
• Did you verify new and existing tests pass locally with your changes?
• Did you list all the breaking changes introduced by this pull request?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:

Reviewer checklist

• Is this pull request ready for review? (if not, please submit in draft mode)
• Check that all items from Before submitting are resolved
• Make sure the title is self-explanatory and the description concisely explains the PR
• Add labels and milestones (and optionally projects) to the PR so it can be classified

[carmocca]

This looks better than before but still doesn't seem ideal to me. Left comments!

[mauvilsa]

@tommycwh I answer your comment since it is about this pull request.

However, I would want some more instructions on how to implement my save_config() function. For example, in my example above, there are some hyperparameters (like those numerical values) that can be saved by the "default" config saving mechanism and I would need to implement my own mechanism for the others that cannot be saved automaically (like the init_args).

I am not sure if I truly understand what you mean or what exactly is it that you want to achieve. This pull request adds save_config such that it can be used however people want to use it. In principle the config is intended for reproducibility and I would save it in a logger as an artifact or a single yaml string which includes any init_args. This is just three lines of code like shown in the example. Doing something different is perfectly fine, but it depends on what you want to do.