Support consumer-provided implementation overrides through Bzlmod module extension

## Summary

Introduce a Bzlmod module extension in `baselibs` that allows consumers to override selected feature implementations through explicit module-level configuration.

## Motivation

`baselibs` has as one of main tasks to acts as the abstraction layer between application code and platform-specific functionality. Today, implementation selection is mostly driven by platform constraint values through `select()` statements.

This works well for selecting default implementations for known platforms, but it does not provide a clean customization point for consumers that need to provide their own implementation of specific features.

Examples include:

* project-specific platform adaptations,
* proprietary vendor integrations,
* replacement of default implementations,
* experimental implementations,
* downstream integration requirements without forking `baselibs`.

The current model makes `baselibs` good as a platform abstraction, but not flexible enough as a consumer-extensible abstraction layer.

## Proposed approach

Introduce a Bzlmod module extension that allows consumers to declare implementation overrides in `MODULE.bazel`.

The module extension should generate a stable repository containing alias targets for overridable `baselibs` features.

`baselibs` code should depend on these stable alias targets instead of directly depending on concrete implementation targets.

For each overridable feature:

* provide a default implementation,
* keep existing platform-based selection where it is still needed,
* expose a module-extension tag that allows the root module to provide a replacement implementation,
* generate aliases that resolve to either the default implementation or the consumer-provided implementation.

Conceptually:

```starlark
baselibs = use_extension("@baselibs//:extensions.bzl", "baselibs")

baselibs.override(
feature = "time",
implementation = "//platform/my_time:implementation",
)

use_repo(baselibs, "baselibs_impls")
```

Then internal `baselibs` targets depend on stable labels such as:

```starlark
@baselibs_impls//time:implementation
```

## Expected behavior

Consumers that do not configure overrides continue to use the current default implementations.

Consumers that configure overrides can replace selected implementations without modifying or patching `baselibs`.

Platform constraint-based selection remains valid for default implementation selection, but consumer customization is handled explicitly through the module extension.

## Acceptance Criteria

* A Bzlmod module extension exists for declaring implementation overrides.
* At least one selected `baselibs` feature is migrated to use the generated indirection repository.
* Existing builds without overrides remain unchanged.
* A consumer can provide a custom implementation from the root module.
* Documentation explains how to configure an override in `MODULE.bazel`.
* The design clearly defines which features are considered overridable extension points.

## Non-goals

* Do not replace all platform-based `select()` statements.
* Do not introduce command-line build flags for implementation selection.
* Do not require consumers to fork or patch `baselibs`.
* Do not make every internal implementation detail overridable by default.

## Benefits

* Provides a well-defined extension mechanism for consumers.
* Keeps platform defaults centralized in `baselibs`.
* Reduces downstream forks and local patches.
* Makes implementation customization explicit and reviewable.
* Aligns customization with Bzlmod dependency resolution instead of build-time configuration flags.