Grmtools section array values

[ratmice]

Here is a first working attempt at adding array values to the grmtools section, and migrating the test_files to using that.

I also did some manual testing, e.g. that adding "*.bad_input" to the calc_input.test causes a testsuite failure.

[ltratt]

My only minor overall comment is that none of the tests -- I think! -- use more than 1 element in the array?

[ratmice]

The two in 60df6f9 calc_input and ctfails/calc_bad_input both use multiple values. In the first one, i added the same glob twice.
In the second one, it parses both the good inputs from calc_input and the .bad_input files.

But actually now that I think about it this latter case is probably unreliable because of multi-threaded test runners and the globbing may be spuriously matching an empty set of files.

These should really only be matching files within the .test

[ltratt]

I think the "same glob" twice probably isn't worth it (and I'd probably remove it to avoid confusing later readers): buggy code could just "accidentally" reuse the first glob, and the outcome would be the same. The second case seems sensible, although maybe we can make it rely on some set of files that we know will exist? But that might be hard.

[ratmice]

I'll add some more files to the extra_files dict, using a different extension, and glob those, should be easy.

[ltratt]

Good idea!

[ltratt]

I think this is ready to squash; and then we're ready to make a release?

[ratmice]

I think so too, I'll squash it in the morning after having another look over it, in case I can think of anything else and also because I'm likely too tired to squash it without making a mess of everything.

Edit: I should probably do another PR going over any clippy lints that may have crept in

[ratmice]

The only thing that came to mind over night was the behavior when a glob matches zero files,
currently we allow this and treat it as success. We could also complain though, and that would catch
cases where you have a typo in the glob, say test_files: ["*.fo"] when you have inputs input1.foo.

I could probably argue for either, but changing it for typo resistance seems worth considering.

[ltratt]

Good point! Experience suggests to me that it's better if we error if there are no matches.

[ratmice]

I added that in e91fa58 it turns out that nimbleparse was already working that way,
so now CTLexerBuilder and nimbleparse match behavior.

[ltratt]

Please squash.

[ratmice]

Squashed