Allow configuration aliases

[Erotemic]

What does this PR do?

This is a proof of concept that allows for aliases in config files. I've found that it works in my use case, but I don't know if it properly fits into jsonargparse the way it is currently written. I would like guidance on how this feature might be sustainably integrated.

The current change is this: If a the user defines a parse action that has multiple option strings, the normalized form of those names is now a valid config key that the user can specify in a yaml config and it maps to the dest name of the corresponding action.

Thus if the underlying ArgumentParser has an action that could be specified on the commandline as --foo=1 or --bar=1, then it can now also accept a configuration dictionary specified as foo: 1 or bar: 1. Here is an example:

    import jsonargparse
    parser = jsonargparse.ArgumentParser()
    parser.add_argument('--foo', '--bar')
    parsed = parser.parse_string('foo: 3')
    print(parsed)
    parsed = parser.parse_string('bar: 2')
    print(parsed)
    parsed = parser.parse_args(['--bar', '4'])
    print(parsed)

Currently prints:

Namespace(foo=3)
Namespace(foo=2, bar=2)
Namespace(foo='4')

In the second case I could probably fix it so it doesn't populate the alias name as well and always uses the primary key, but I'll leave that as TODO until I get feedback.

This PR has to do with #244, where I use scriptconfig to help define these aliases. Having access to aliases is important to me because it makes it much easier to transition / update variable names. I can give users a grace period where the old and new name are treated equally before writing specialized deprecation code, and finally removing the alias. Sometimes aliases are useful as permanent structures because it lets you define a CLI that works with multiple people's intuitions. Of course aliases do have drawbacks, but I hope maintainers see enough value in this feature to help me refine and merge this PR.

Before submitting

• [ ] Did you read the contributing guideline?
• [ ] Did you update the documentation? (readme and public docstrings)
• [ ] Did you write unit tests such that there is 100% coverage on related code? (required for bug fixes and new features)
• [ ] Did you verify that new and existing tests pass locally?
• [ ] Did you make sure that all changes preserve backward compatibility?
• [ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or minor internal changes/refactors)

I have not done all before submitting tasks because I need feedback before I can prepare something that is merge-ready.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[mauvilsa]

Sounds good to add support for aliases in config files. Makes it more consistent when an argument has several option strings. Thank you for working on this. I will add comments on the code for guidance.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication