Create new Argument class for options

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🔨 Refactoring

Description

I've looked into argparse and the move from optparse towards it. This is still a long road ahead. We would need to rewrite (almost) every bit of code dealing with options and config.

I've thought about the best way to do this and think the best way might be to start preparing the codebase by duplicating some functionality/data and slowly preparing a final move. It helps that the terminology of argparse relies on arguments instead of options, which allows duplicating methods and attributes with similar though different names.
Before continuing with this I would like some response from maintainers if this is indeed the best way to do this, or if there are other ways to allow for a gradual change to argparse.

This PR is a first step towards this gradual transformation. I have created a new NamedTuple and one that inherits from it. These are based on the parameters we would eventually need to pass to ArgumentParser.add_argument(). For now I would suggest to add duplicate all options of all checkers into an arguments attributes. If all checkers have an arguments attribute we can then start working on methods that utilise this (for example the documentation creation methods).
The StoreArgument is probably not the only type of subclassed NamedTuple I will need to create to do this, but serves as an example of how subclassing Argument would work.

TLDR: 1) Is temporary duplication the best way to facilitate the move towards argparse? 2) Is the use of Argument NamedTuples's a good way to store arguments data?

[coveralls]

Pull Request Test Coverage Report for Build 1339360339

• 21 of 21 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.01%) to 93.222%

---

Totals
Change from base Build 1337381471:	0.01%
Covered Lines:	13602
Relevant Lines:	14591

---

💛 - Coveralls

[cdce8p]

I would suggest to focus on 2.12 for now and look at this only afterwards, ie. for 2.13. Still some other things to sort out first.

[Pierre-Sassoulas]

Thank you for starting this, this is indeed an enormous refactor that we need to do before python 3.12 if I remember correctly. I have some ideas about it but I agree with @cdce8p let's talk about it later.

[DanielNoord]

@Pierre-Sassoulas Seeing your recent issue (#5259) also mentions the change to argparse it seems we're slowly building up a list of issues/enhancements that are waiting or depending on the move to argparse. You said you and @cdce8p had some thoughts about this as well so it might be time to start aggregating those and create a clear roadmap to follow.

I'm not sure how you did this for previous big changes but making an issue with a to-do list or even a project might allow me and other contributors to help the process along!

[DanielNoord]

Closing this in favour of #5584 which I believe is a much better approach.