Move `DurationSinceUnixEpoch` from `torrust-tracker-primitives` to `torrust-tracker-clock`

[josecelano]

Goal

Move the DurationSinceUnixEpoch type alias from torrust-tracker-primitives into
torrust-tracker-clock — where it semantically belongs — and update all workspace consumers
to import it from torrust-tracker-clock. This removes the torrust-tracker-primitives
dependency from torrust-tracker-clock, preparing the crate for future extraction to a
standalone repository.

Background

DurationSinceUnixEpoch is defined in packages/primitives/src/lib.rs as:

pub type DurationSinceUnixEpoch = Duration;

It is a trivial alias for std::time::Duration with no tracker-specific logic. The
torrust-tracker-clock package is the primary user of this type: it appears in the Clock
trait itself (fn now() -> DurationSinceUnixEpoch) and in the conversion helpers
(packages/clock/src/conv/mod.rs). Having it live in torrust-tracker-primitives is an
accident of history, not a design intent.

torrust-tracker-clock currently carries a torrust-tracker-primitives dependency solely
for this type alias. Removing it makes torrust-tracker-clock dependency-lighter and
prepares it for future rename/extraction (SI-09, SI-13).

Key implementation note: Since DurationSinceUnixEpoch is a trivial type alias (both
the old and new definitions are = std::time::Duration), there is no type incompatibility
between torrust_tracker_primitives::DurationSinceUnixEpoch and
torrust_tracker_clock::DurationSinceUnixEpoch. All 80+ workspace files that currently
import the type from torrust-tracker-primitives need only a trivial import path change.

Circular dep constraint: torrust-tracker-primitives must not re-export the type
from torrust-tracker-clock. That would introduce a new torrust-tracker-primitives →
torrust-tracker-clock dependency edge. Instead, torrust-tracker-primitives retains its
own independent pub type DurationSinceUnixEpoch = Duration definition. Once all workspace
consumers have been migrated to torrust_tracker_clock::DurationSinceUnixEpoch, the copy
in torrust-tracker-primitives can be deprecated and removed in a future cleanup.

This issue is a subissue of EPIC #1669 (Overhaul: Packages).

Scope

In Scope

• Add pub type DurationSinceUnixEpoch = std::time::Duration; to packages/clock/src/lib.rs
  (or a dedicated types.rs module), exported as part of the public API.
• Update packages/clock/src/clock/mod.rs and packages/clock/src/conv/mod.rs to use the
  local definition instead of importing from torrust-tracker-primitives.
• Remove the torrust-tracker-primitives dependency from packages/clock/Cargo.toml
  (it was added only for this type alias).
• Update all 80+ workspace files that import DurationSinceUnixEpoch from
  torrust_tracker_primitives to import it from torrust_tracker_clock instead.
• Verify the workspace builds and all tests pass.
• Update torrust-tracker-metrics to import DurationSinceUnixEpoch from
  torrust-tracker-clock instead of torrust-tracker-primitives, eliminating that
  dependency edge entirely.

Out of Scope

• Removing DurationSinceUnixEpoch from torrust-tracker-primitives: that requires a
  crates.io version bump to signal the breaking change; deferred to a separate cleanup
  subissue once all consumers have migrated.
• Changes to the type itself — it stays = std::time::Duration.
• Extracting torrust-tracker-clock to a standalone repository (a separate, later subissue).
• Renaming torrust-tracker-clock to torrust-clock (tracked in SI-09, a separate subissue).

Acceptance Criteria

• packages/clock/src/lib.rs (or a submodule) exports pub type DurationSinceUnixEpoch = std::time::Duration.
• packages/clock/Cargo.toml does not list torrust-tracker-primitives as a dependency.
• No file in packages/clock/src/ imports DurationSinceUnixEpoch from torrust_tracker_primitives.
• No other workspace file imports DurationSinceUnixEpoch from torrust_tracker_primitives (all migrated to torrust_tracker_clock).
• torrust-tracker-metrics no longer lists torrust-tracker-primitives as a dependency (or only lists it for non-DurationSinceUnixEpoch reasons).
• cargo build --workspace succeeds with zero errors.
• cargo test --workspace passes with zero failures.
• linter all exits with code 0.

Related to #1669