Fix any() assertion combinator to correctly resolve OR semantics

[94xhn]

Problem

As reported in #595, the any() assertion combinator does not actually
combine its sub-assertions with OR semantics. Instead, the result silently
collapses to the truth value of the last sub-argument:

Test(assertion, testing)
{
    cr_expect(any(eq(int, 0, 1), eq(int, 0, 2), eq(int, 3, 3))); // Passes
    cr_expect(any(eq(int, 0, 1), eq(int, 2, 2), eq(int, 0, 3))); // Fails but should pass
    cr_expect(any(eq(int, 1, 1), eq(int, 0, 2), eq(int, 0, 3))); // Fails but should pass
}

Root cause

Two separate issues in include/criterion/internal/new_asserts.h
combine to produce this behavior:

1. CRI_ASSERT_SPECIFIER_ANY_INDIRECT splices each sub-assertion's raw
   expansion directly into Cond = Cond || <expansion>, instead of first
   assigning it to its own temporary (cri_cond_un) like the sibling
   ALL_INDIRECT/NONE_INDIRECT macros do.

2. CRI_ASSERT_SPECIFIER_any combines the final accumulated result with
   *cri_pass = *cri_pass && cri_cond; — using && instead of the
   combinator's own || operator. For all()/none() this is
   coincidentally harmless (AND-absorption with 0 holds for an AND-chain),
   but for any() the combinator can be correctly true even when the last
   evaluated leaf is false — exactly the reported scenario — so ANDing the
   correct cri_cond with a stale residual wrongly forces the result to 0.

Both edits are needed together; applying only the first is not sufficient
to fix #595 (verified by testing).

Fix

• CRI_ASSERT_SPECIFIER_ANY_INDIRECT: assign the sub-assertion result to
  cri_cond_un first, then Cond = Cond || cri_cond_un (mirrors
  ALL_INDIRECT).
• CRI_ASSERT_SPECIFIER_any: change *cri_pass = *cri_pass && cri_cond;
  to *cri_pass = *cri_pass || cri_cond; (mirrors how all()/none()
  each combine using their own operator).

Testing

Verified against the real, unmodified header by compiling the macro
expansion with a minimal stub runtime (the small set of
cri_assert_node_*/criterion_*_test support functions), since the full
meson build wasn't viable in the sandbox. Before the fix, both
any(1==1, 2==2, 0==3) and any(0==1, 2==2, 0==3) (the exact shapes from
#595) incorrectly reported failure. After the fix, both correctly pass,
and all()/none() sanity cases are unaffected (no regression).

Fixes #595

[MrAnno]

Thank you!