WIP: Allow user provided arguments to CLI

[kainctl]

Hey, this is a draft PR to better discuss the implementation details of #64.
Once we have agreed on the rough plan, I will create a new PR (or squash these debug commits) and remove debug.lua, inspect.lua etc.
For now, I have kept everything local to the d2 engine for simplicity.
I have added TODO comments to highlight things that are possibly worth discussing.
In general, the goal is to support the following four argument types:

• A "normal" attribute-like key-value pair like: --theme=100 and the short version -t=100
• An "empty" key-value pair like: --section= and the short version -s=
• Flags that have no values like: --bundle and the short version -b
• Positional arguments (though this is probably the least important and may be "hidden") like POSARG

I propose to prefix these options with args or arg and simply match everything after it.
So for a user:

• args--theme=100 -> --theme=100
• args-s= -> -s=
• argsPOSARG -> POSARG

I find this less confusing than prefixing it with args- where you need --- to get a double minus -- especially
since this will be the common case. And if we are not too strict with the pattern, the code could also support flags that start with a + like arg+plus-opt, though the current CLI tools do not use it.

From the implementation viewpoint, the key-value flags can simply be processed by pandoc attributes and the
flags and positional arguments via classes. I have yet to find corner-cases with this approach, though I wouldn't be surprised if there would be issues. In that case, a user would have to fall back to the quarto-style options.

This draft does not contain any global option, as I would like to first check if this is going in the right direction.

[tarleb]

Thank you! I didn't have time yet to take a closer look. Please ping me again if I haven't replied by the end of next week.

[kainctl]

No pressure.
I am aware that one will get to FOSS work when one gets to it 👍