Initial qmk test-c functionality

[zvecr]

Description

Adds CLI subcommand that extends the available functionality of normal test execution.

Adds:

• basic test filtering

Examples

# list available tests
qmk test-c --list

# run all tests
qmk test-c

# clean and run a single test
qmk test-c --clean --test basic

# run all tests that start with "unicode"
qmk test-c --test unicode*

# run all tests with unicode somewhere in the name
qmk test-c --test *unicode*

# parallel compilation
qmk test-c -j=2 --test basic

# environment args
qmk test-c --test basic -e DEBUG=1

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[DavidSannier]

Hello Joel,
With this new "test-c" command, is there still a way to build the tests with DEBUG=1 (and/or other variables) as stated in docs/unit_testing.md ?
Is there also a way to clean only one test like it was with make test:basic:clean ?
Regards

[zvecr]

With this new "test-c" command, is there still a way to build the tests with DEBUG=1

PR description updated. Usual CLI docs will follow once functionality is locked down.

Is there also a way to clean only one test like it was with make test:basic:clean ?

Still working through the various scenarios. This isnt one we currently support via qmk compile / qmk flash, and my initial aim is to somewhat follow what they do. Will have a think as its not directly obvious how we would support that. Nothing would stop the use of the "old" way.

Edit: I think this can wait for a future iteration, as we can still fallback to make invocation.