Improvement: Clarify include path convention for `score/time` public headers

### What

All source files in `score/time` follow the S-CORE folder structure mandated by
the process ([folder.rst](https://github.com/eclipse-score/score/blob/main/docs/contribute/general/folder.rst)):

```
score/time//
├── BUILD ← thin: aliases + test-suite aggregation only
└── src/
├── BUILD ← owns all cc_library / cc_test targets
├── _clock.h ← public API header
├── _clock.cpp
├── _clock_mock.h ← test double
└── details/ ← internal implementation
```

Headers are physically located in `src/`. The Bazel targets that own them are
defined in `src/BUILD`; the root `BUILD` exposes only stable public `alias`
targets (e.g. `//score/time/hpls_time:hpls_time`).

The question is: **what path shall consumers write in their `#include`
directives?**

---

## Current implementation — Option A

Consumer writes:
```cpp
#include "score/time/hpls_time/src/hpls_clock.h"
```

`src/BUILD` carries no `strip_include_prefix` or `include_prefix` attributes.
Files are consumed exactly where they live.

---

## Options

### Option A — Expose `src/` in the include path (no Bazel attributes)

Consumer writes:
```cpp
#include "score/time/hpls_time/src/hpls_clock.h"
```

`src/BUILD`: no extra attributes needed.

**Pro:** Simple BUILD files, honest reflection of physical layout. Works
naturally with the Pattern B BUILD structure (`src/BUILD` owns targets, header
paths have no `src/` prefix inside the package).
**Con:** `src/` leaks into a public API path, which is unconventional for a
library and couples consumers to the internal directory structure.

---

### Option B — Hide `src/` via `strip_include_prefix` + `include_prefix`

Consumer writes:
```cpp
#include "score/time/hpls_time/hpls_clock.h"
```

Each public `cc_library` in `src/BUILD` would carry two extra attributes:
```starlark
cc_library(
name = "hpls_clock",
hdrs = ["hpls_clock.h"],
strip_include_prefix = "/score/time/hpls_time/src",
include_prefix = "score/time/hpls_time",
…
)
```

How it works:
- `strip_include_prefix` (absolute form) removes everything up to and including
`src/` from the compiler search path.
- `include_prefix` prepends the stable package path back.
- Result visible to consumers: `score/time/hpls_time/hpls_clock.h`.
- Files do **not** move; this is purely a compiler `-I` flag manipulation by Bazel.

**Pro:** Clean, stable public path that matches the Bazel label
(`//score/time/hpls_time`) and is independent of internal directory layout.
**Con:** Two Bazel attributes must be maintained on every public `cc_library`
target in `src/BUILD`; the interaction between the two attributes is
non-obvious.

---

## Decision needed

1. Confirm **Option A** as the permanent standard, or switch to **Option B**
before external consumers appear.
2. If Option B: apply `strip_include_prefix` + `include_prefix` only to
**public** targets (`//visibility:public`) or also to **internal** targets
(visibility restricted to `//score/time:__subpackages__`)?

## References

- S-CORE folder structure: `https://github.com/eclipse-score/score/blob/main/docs/contribute/general/folder.rst`
- Bazel `strip_include_prefix` docs:
https://bazel.build/reference/be/c-cpp#cc_library.strip_include_prefix
- Existing precedent in `score_baselibs`: uses `include/` subfolder +
`strip_include_prefix = "include"` for public headers (no `src/` in path).
- Existing precedent in `score/datarouter`: uses `include/` for public headers,
`src/` path exposed as-is for internal headers.

### Estimates for realization

1 day

### Category

- [x] Affects Detailed Design

### Requirements / Architecture

- [x] Requirements / Architecture are not affected by this change?