ci:ctest timing summary for MacOS

[dougch]

Description of changes:

Our macOS CI jobs run several build configurations sequentially, making it hard to identify which tests are the long poles. This PR adds per-test-case timing by capturing gtest's native JSON reports and surfaces the top 20 slowest tests in the GitHub Actions step summary for both the macOS-x86 (FIPS) and macOS-ARM jobs.

Changes:

• In util/all_tests.go, when GTEST_REPORT_DIR is set, pass GTEST_OUTPUT=json:<file> to each test binary so gtest emits a per-test-case timing report. Report filenames include the binary name, shard index, and PID so sequential/sharded runs don't overwrite each other.
• Add tests/ci/test_results_summary.py, which aggregates all gtest JSON reports in the directory and emits a markdown table of the slowest test cases to the step summary.
• Wire GTEST_REPORT_DIR and a Test timing summary step (if: always()) into the macOS-x86 (FIPS) and macOS-ARM jobs in actions-ci.yml.

Call-outs:

1. This is just a sample; not all jobs that could emit slow test data were set up.
2. With the size of these workflows, this table format might not scale/be readable — 20 entries that are ~1 sec apart might not be that useful.
3. Does this data belong in CloudWatch instead/also? Are these metrics actionable ?

Testing:

This PR; see an example Summary.
For each arch the python script creates a top-20 slowest-tests table; an in-line example:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.16%. Comparing base (84b74e0) to head (9a00d43).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3288      +/-   ##
==========================================
- Coverage   78.33%   78.16%   -0.18%     
==========================================
  Files         693      693              
  Lines      123786   123783       -3     
  Branches    17196    17191       -5     
==========================================
- Hits        96972    96749     -223     
- Misses      25891    26114     +223     
+ Partials      923      920       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[WillChilds-Klein]

This is just a sample; not all jobs that could emit slow test data were set up.

why not just time all tests and only show the 20 slowest in the summary?

Does this data belong in CloudWatch instead/also? Are these metrics actionable ?

i would vote just keeping it here. if you're annoyed with slow runtime on a test/PR you care about you can check the summary right from the PR. timing might fluctuate by run and over time, so adequately tuning some alarm threshold seems brittle.

[justsmth]

Looks good -- I have just one lingering "uniqueness" concern.

[justsmth]

Sorry -- I think the PID would still be needed for uniqueness across iterations:

reportFile := filepath.Join(reportDir, fmt.Sprintf("%s_shard_%d_%d_%d.json",
    binName, test.shard, os.Getpid(), atomic.AddInt64(&reportSeq, 1)))