new getCapturedMsgs API to capture the messages output by compiler, for testing

[timotheecour]

rationale:

• easier to read test when the warning/hint message being issued is tested right below the code that triggers it as opposed to on top in a testament spec section, especially if a lot of messages are generated and it's hard to identify where they come from in code
• makes it suitable for writing tests without testament (for user code that doesn't want to use testament)
• avoids having to write a separate "runner" (whether it's testament or some code that compiles a nim program and collects the stderr of compilation process) just to check the messages

it also allows arbitrary user defined logic on the generated messages, without having to bake it in the compiler (or testament)

I'm heavily relying on this feature in #14976 , see tests/misc/tviewfroms.nim which reads much better with the assert conditions on the generated compiler messages (warnings, in this case) appearing right below the expression that triggers them, rather than lumped at the top. This makes the tests self documenting and makes it easier to move things around for example without having to change the section at the top.

[Araq]

We can also improve testament instead so that you can write the expected output messages after the line it should occur.

[juancarlospaco]

I dont think we should duplicate testament features directly in the compiler. Code looks good.
🤔

[Varriount]

Just to confirm, this is only for compiler testing, right? Not for other libraries to use? I wouldn't want exact compiler output to be added to the list of backwards-compatible mechanisms.

[Araq]

Just to confirm, this is only for compiler testing, right?

I hope so.

Not for other libraries to use? I wouldn't want exact compiler output to be added to the list of backwards-compatible mechanisms.

Exactly. And easier testing can also be done with a testament patch.

[Araq]

Replaced by #15294