Add integration tests for CvCascadeClassifier::train

[vladiant]

Summary

Extend the test suite with end-to-end integration tests that exercise the
real cascade training pipeline (CvCascadeClassifier::train) against the
sample resources bundled in traincascade/res/. These complement the
existing unit tests by covering the wiring between CvCascadeImageReader,
the feature evaluators and the boosted-tree trainer through one full stage.

Coverage of the traincascade/lib/ library jumped from 9.6% to
41.1% of lines (and 76.0% of functions) thanks to these tests.

Changes

traincascade/test/test_integration.cpp (new)

Five integration tests, all strictly following the Arrange / Act / Assert
pattern with explicit comments per step:

#	Test case	What it validates
1	LBP stage trains and emits cascade.xml	Happy path with featureType=LBP, boostType=GENTLE
2	HAAR (BASIC) stage trains and emits cascade.xml	Happy path with featureType=HAAR, mode=BASIC
3	baseFormatSave=true produces a non-empty cascade	HAAR-only legacy save format
4	Missing .vec file → train returns false	Error path: image reader cannot be created
5	Empty cascade dir → train throws	Error path: params.xml cannot be opened

Helpers introduced:

• makeUniqueOutputDir(tag) — per-test isolation under
  /tmp/traincascade_it/<timestamp>_<random>_<tag>/.
• stageResources(workDir) — copies barcode.vec, synthesizes a
  256×128 deterministic-texture negative image, and writes a bg.txt
  with an absolute path so the negative reader resolves regardless of
  the current working directory.

traincascade/CMakeLists.txt

• Add test/test_integration.cpp to the test_traincascade target.
• Inject the resource directory at compile time via
  TRAINCASCADE_RES_DIR="${CMAKE_CURRENT_SOURCE_DIR}/res" so tests are
  CWD-independent.

Why a synthetic negative image?

The bundled res/bg.png is 32×32, but barcode.vec hard-codes a 75×32
detection window. The negative reader cannot slide a 75×32 window over a
32×32 source; the resulting cv::Mat violates _step >= minstep and
training aborts. The tests therefore generate a 256×128 grayscale image
in-memory (deterministic pattern, no extra resource file) and reference it
from a freshly-generated bg.txt.

Test results

[doctest] test cases:  61 |  61 passed | 0 failed | 0 skipped
[doctest] assertions: 220 | 220 passed | 0 failed |
[doctest] Status: SUCCESS!

ctest: 100% tests passed, 0 tests failed out of 1
Total Test time (real) =  17.5 sec

CI parity verified locally on Linux (g++ 13.3 + clang 18). The runtime is
within an acceptable budget for the existing GitHub Actions Test step on
ubuntu, macos and windows workflows.

Coverage impact

Metric	Before	After
Lines	9.6%	41.1% (1921 / 4676)
Functions	—	76.0% (196 / 258)
Branches	—	25.6% (1280 / 5006)

Modules now ≥ 85% line coverage:
o_cvboostparams.cpp, o_cvdtreeparams.cpp, o_cvstatmodel.cpp,
o_utils.cpp, o_cvboost.cpp, lbpfeatures.cpp, imagestorage.cpp,
features.cpp.

Risks / Notes

• Each integration test creates a unique temp directory; nothing is left
  behind in the repo. Cleanup is intentionally not done so failing
  runs leave artifacts available for inspection.
• The tests pin a single-stage, maxWeakCount=10, maxDepth=1
  configuration to keep CI runtime under ~20s.
• HOG features and Haar CORE/ALL modes remain uncovered — flagged as
  a follow-up.

Checklist

• All 61 tests pass locally (ctest --output-on-failure)
• AAA pattern with comments in every test
• Happy paths and edge cases covered
• No new resource files committed (negative image is synthesized)
• No changes to library code