fix: make C test builds reliable across platforms

[ping-ke]

Summary

Make the C test build fail immediately when its required Boost components are unavailable.

Changes

• Mark the Boost filesystem, system, and unit-test framework components as REQUIRED in test/c/CMakeLists.txt.

Behavior Changes

Missing Boost components now cause CMake configuration to fail explicitly. Previously, CMake could omit the Test target, allowing make rebuild to report success even though build/test/c/Test was not generated.

No behavior changes are expected when all required Boost components are available.

Validation

After change, you need see following log if Boost missing.

make

./build.sh
-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES MPI_CXX_HEADER_DIR MPI_CXX_WORKS)
-- Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND)
-- Could NOT find CryptoPP (missing:  CRYPTOPP_ROOT_DIR CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY) (Required is at least version "5.6.2")
... ...

[qizhou]

If the PR is intended to fix the build problem, other non-build-related files (e.g., test/python/test_pyethash.py, test.cpp) should not be changed.

[qzhodl]

If this PR is intended to fix #2, I think a much smaller change should be sufficient. For example, changing the Boost lookup in test/c/CMakeLists.txt to:

find_package(Boost 1.48.0 REQUIRED COMPONENTS unit_test_framework system filesystem)

would make CMake configuration fail immediately when the required Boost components are unavailable, instead of silently omitting the Test target and allowing make rebuild to report success. Explicitly building or validating the Test target in build.sh could be added as a small defensive check if desired.

The current PR has expanded into a broader rework and hardening of the entire cross-platform C/C++ build workflow, including Boost discovery, build stamps, multi-config generator handling, benchmark targets, artifact discovery, and documentation. These may be useful improvements, but they require substantially more review effort and make the change less safe than a focused fix. Could we keep this PR narrowly scoped to #2?

[qzhodl]

The PR description does not match the change now

[ping-ke]

The PR description does not match the change now

Updated