[wilx]

Fixes #862.
Fixes #3178.

Summary

Failsafe 3.3.1 stopped writing a summary file when an integration-test
execution runs no tests. This is intentional, but VerifyMojo still tried
to read every path configured through summaryFiles, causing verification
of POM modules to fail with FileNotFoundException.

The same missing summary also caused verify to return before the normal
failIfNoTests check, so an empty discovered test class incorrectly produced
a successful build even with failIfNoTests=true.

This change:

• filters configured summary files to those that actually exist;
• logs each missing summary file at DEBUG level;
• routes a missing-summary result through normal reporting when
  failIfNoTests=true;
• retains the normal failure when an existing summary reports test failures;
• adds unit coverage for missing, mixed, and fail-if-no-tests summary cases;
• adds integration tests reproducing Build of pom modules broken #862 and failIfNoTests=true with failsafe-plugin does not fail even if verify stage shows No tests to run. #3178.

Validation

• mvn clean install with JDK 17: passed (all 17 reactor modules).
• mvn -Prun-its clean install with JDK 17: passed (760 tests,
  0 failures, 0 errors, 153 skipped).
• Focused VerifyMojoTest unit tests: 6 tests passed.
• Surefire862MissingSummaryFilesIT: 1 integration test passed.
• Surefire3178FailIfNoTestsIT: 1 integration test passed through the
  run-its profile.
• The reproducer linked from Build of pom modules broken #862 succeeds with the locally built snapshot.
• The reproducer from failIfNoTests=true with failsafe-plugin does not fail even if verify stage shows No tests to run. #3178 fails as configured with the locally built
  snapshot; its reported 3.3.0 failure and 3.3.1 success were also reproduced.

The JDK 8 build in this environment is blocked by the unrelated existing
ProcessCheckerTest.shouldHavePidAtBegin start-time assertion; the same test
and both complete builds pass with JDK 17.

Following this checklist to help us incorporate your
contribution quickly and easily:

• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean install to make sure basic checks pass. A more thorough check will
  be performed on your pull request automatically.
• You have run the integration tests successfully (mvn -Prun-its clean install).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.