Add custom argparse actions

[Pennycook]

Related issues

• Part of Support custom compiler arguments #145; these two actions are required to configure argparse such that its behavior is equivalent to the custom argument handling code introduced in CBI 1.2.0.

Proposed changes

• Add _StoreSplitAction to handle comma-delimited arguments (e.g., -fsycl-targets=t1,t2).
• Add _ExtendMatchAction to handle arguments requiring regular expressions (e.g., --gencode=sm_70,compute_75).
• Add tests for both new actions.

---

Recognizing custom compiler arguments is a big feature, so I'm going to try and split it out into bite-sized chunks for review.

[laserkelvin]

Just general comment - not sure if you want to add type annotations to the function signatures: even though the classes are private, would make it easier to maintain if you can glean argument types from a glance

[Pennycook]

Just general comment - not sure if you want to add type annotations to the function signatures: even though the classes are private, would make it easier to maintain if you can glean argument types from a glance

Good idea. I've done this in 1430ab6. I didn't add annotations for kwargs, mainly because I don't know what they should be -- we pass the kwargs along to argparse, and the remaining arguments can be pretty much anything. I think the fact the argument is called kwargs explains what it is, though.

[Pennycook]

The CI reports the following lines as being uncovered:

6 uncovered lines in codebasin/__main__.py: 271,272,327,335,341,354
1 uncovered lines in codebasin/config.py: 280
1 uncovered lines in codebasin/preprocessor.py: 691
19 uncovered lines in codebasin/report.py: 46,47,49,50,175,205,227,258,293,294,296,357,358,368,369,795,796,800,805

None of these lines were actually touched by this PR, so the action is being a little overzealous. I'm going to ignore it and merge anyway, but I need to take another look at why the coverage action keeps generating the wrong list of commits.