GCC is especially bad, as it had quadratic scaling in the number of
registered test cases in a TU, but Clang also scaled superlinearly, and
this commit fixes both.

AIUI:
1) Each `TEST_CASE` creates a separate global fragment to handle creating
   the `unique_ptr<ITestInvoker>`, moving the instance into AutoReg,
   destroying the old instance, etc, etc.
2) With optimizations enabled, the compiler merges all these global
   fragments into one big global fragment.
3) Then the compiler runs various optimizations passes on this new global
   fragment.
4) Because some of the passes scale superlinearly, the compilation times
   scale superlinearly in the number of `TEST_CASE` in a translation unit.

For bonus point, no optimization actually happens.

This commit fixes the problem (for non-LTO builds) by adding new `AutoReg`
constructor, one that takes the function pointer raw, instead of wrapped
in `ITestInvoker`. By delaying the construction of the `ITestInvoker`
into the outlined constructor, we no longer create big global fragments
for the compiler to optimize.

This provides further speed-ups for TUs with many test cases templated
over the same set of types. For especially test-heavy (but still
realistic) TUs, the speed up is up to 20%.

* fix: work around clang 20/21 + libc++ compile failure in TEMPLATE_PRODUCT_TEST_CASE with differing arities

Fixes #3115

* docs: reference llvm/llvm-project#130778 in the clang 20/21 workaround comment

---------

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>

Closes #2582

Right now `TEMPLATE_TEST_CASE_SIG` fails to compile when the signature contains only types:

```
TEMPLATE_TEST_CASE_SIG(
  "TemplateTestSig: compiles with two type parameters",
  "[template][onlytypes]",
  ((typename U, typename V), U, V), (int,int)) {}
```

The trick is to resolve the ambiguity between the two overloads of
`get_wrapper` (`TypeList` and `Nttp`) by making one match more strongly.
We also need to allow `reg_test` to register more than one type.

Add unit tests.

Fixes #2680

---------

Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>