feat: add TimeDaemon CIT with pip hub infrastructure

[gordon9901]

This PR adds TimeDaemon component integration tests with pip hub infrastructure (part 1 of 3):

• Add three independent pip hubs for TimeDaemon, TimeSlave, and MIT test suites
• Add score_test_scenarios framework dependency with compatibility patch for score_baselibs 0.2.7
• Add TimeDaemon CIT covering daemon lifecycle, control flow, IPC, SVT, and verification pipeline
• Fix visibility for shm_ptp_engine and svt_handler to allow access from test scenarios

Part of #56

test QNX

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 63f8dd70-036a-43c0-82cf-8fa3ef85f899
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'platforms', the root module requires module version platforms@1.0.0, but got platforms@1.1.0 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 3 packages loaded
Analyzing: target //:license-check (4 packages loaded, 0 targets configured)
Analyzing: target //:license-check (4 packages loaded, 0 targets configured)

Analyzing: target //:license-check (70 packages loaded, 10 targets configured)

Analyzing: target //:license-check (91 packages loaded, 10 targets configured)

Analyzing: target //:license-check (151 packages loaded, 3143 targets configured)

Analyzing: target //:license-check (161 packages loaded, 3906 targets configured)

Analyzing: target //:license-check (161 packages loaded, 8156 targets configured)

Analyzing: target //:license-check (172 packages loaded, 9417 targets configured)

Analyzing: target //:license-check (172 packages loaded, 9417 targets configured)

Analyzing: target //:license-check (172 packages loaded, 9417 targets configured)

Analyzing: target //:license-check (172 packages loaded, 9417 targets configured)

Analyzing: target //:license-check (176 packages loaded, 11429 targets configured)

INFO: Analyzed target //:license-check (177 packages loaded, 11555 targets configured).
[3 / 14] checking cached actions
INFO: From Generating Dash formatted dependency file ...:
INFO: Successfully converted 2 packages from Cargo.lock to bazel-out/k8-fastbuild/bin/formatted.txt
[14 / 16] [Prepa] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 31.459s, Critical Path: 2.64s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[BjoernAtBosch]

Sorry, I don't understand this: What is the benefit of using the combination of the pytest/testing_utils plus C++ code over using plain gtest/gmock? At the moment it looks to me making things more complicated and harder to understand.

Imho, for all the component internal testing, I would use gtest. That doesn't mean that everything tested with gtest is automatically a unit test (in the strict sense), it can be also some sort of integration tests - i.e. test which integrate multiple classes and test them together.

Then on the level of testing the whole component as a binary - TimeDaemon in this case - I'd use some pytests framework or ITF to stimulate and test the binary from "outside". And next step would be testing of multiple binaries "playing together".