[capture] Naming convention for capture commands

[vrozic]

Test capture script #150 uncovered a problem with naming of some of the capture commands and arguments. At the moment we don't use consistent naming strategy, which makes it complicated to automate the testing. Since the repository is likely to be extended with newer tests, we should come up with a consistent naming strategy to make maintaining easier.
Tasks:

• Document the naming strategy
• Modify capture.py and the test scripts.

[m-temp]

It would be also great if we could shorten the command line by:

• allowing for a single argument/parameter to a config file that covers all parameters / (sub)commands
• omitting the "capture" command. ./caputre.py [...] capture [...] as there is no other main command.

[johannheyszl]

We could discuss tomorrow in the SCA subgroup. With @bilgiday and @vogelpi we are thinking about a more extensive refactor where instead of one capture file with command line parsing, we use one file per test.

• This would probably allow to remove the complexity that the Typer command line parsing brings (thinking this is why it need the "capture" command), and
• allow us have all settings per test in a single Python (and/or dedicated config) file.
  I think we should go this way instead of fixing the complicated capture.py. The issues @vrozic describes above reinforce my view on this ;)

[vrozic]

I agree we should add this to the agenda for tomorrow.

• I think we should go this way instead of fixing the complicated capture.py. The issues @vrozic describes above reinforce my view on this ;)

I'm afraid that we find ourselves in the catch-22 situation. The intention here #150 was that we setup some form of CI/nightly-regressions before we start making big changes with the capture, and to make that easier/possible we need to do some clean-ups of the existing capture script.