testament: add flags (more flexible than matrix, cmd, targets)

[timotheecour]

proposal

add options testament spec; this generalizes targets, cmd, and matrix. In particular, this allows specifying different options per backend, where some option combinations would either be non-meaningful for a backend or redundant, avoiding combinatorial explosion.

example

discard """
  flags: “js"
  flags: “js -u:nodejs" # -u:nodejs will override the default added -d:nodejs
  flags: “c —threads:on"
  flags: “c —threads:on -d:ssl"
  flags: “$target -d:foo"
    # $target honors default target, which depends (currently) on `NIM_COMPILE_TO_CPP`
  flags: “r -b:cpp"
  flags: “doc —doccmd:-d:foo"
"""

doAssert true

benefits

• faster CI by avoiding redundant combinations
• allows testing other backends without having to jump through hoops (eg --threads:on currently breaks js, refs js should ignore threads:on Nim#17267)

implementation

testament will then run:

$nim $options $flags $file

where $options is already defined in testament as default options to use; note that $flags can override those

alternative

allow multiple cmd entries (currently only 1 possible)

```nim
discard """
  cmd: “$nim c $options $file"
  cmd: “$nim c --threads:on $options $file"
  cmd: “$nim js $options $file"
"""
doAssert true

but cmd in most cases would have the redundant prefix $nim and $options $file, so flags is IMO a simple but useful sugar.

note that we can still also support multiple cmd entries, for those cases where the cmd to run doesn't fit a pattern like “$nim c $options $file" (eg: no $options, or arguemnts after $file, etc)

[Araq]

I prefer the flags, however multiple cmd have their own advantage, we can then test for both nim c and nim check, for example. We should do whatever is easier to implement IMHO.