ContainerLog: add metadataProvider to LogHandler implementations

[ArasanDev]

Type of Change

• Bug fix

Motivation and Context

Resolves #1754.

The LogHandler protocol in swift-log 1.5+ requires conforming types to
declare var metadataProvider: Logger.MetadataProvider? { get set }. The
three handlers in ContainerLog — StderrLogHandler, OSLogHandler,
and FileLogHandler — were missing this property. The protocol's default
extension emits a runtime warning in DEBUG builds whenever a
MetadataProvider is attached to a handler that doesn't implement the
property, which surfaces as build noise in downstream projects that import
ContainerLog (e.g. reported in #1754 via stephenlclarke/container-compose).

Changes per handler:

• StderrLogHandler: Added metadataProvider property. Also corrected
  a pre-existing gap: the original log() used only the per-call metadata
  parameter and silently ignored handler-level self.metadata. The updated
  implementation merges all three sources in the canonical priority order
  (handler-level → provider → per-call), matching StreamLogHandler.prepareMetadata.

• OSLogHandler: Added metadataProvider property. Removed the
  formattedMetadata cache and its didSet observer — a dynamic provider
  (which may read task-local values) requires per-call computation, making
  the cached value incorrect. Updated log() to merge all three sources in
  the same priority order.

• FileLogHandler: Added metadataProvider property. Inserted the
  provider merge step between handler-level and per-call metadata in the
  existing log() merge sequence.

All three handlers now follow the merge order defined in
StreamLogHandler.prepareMetadata: handler-level metadata as the base,
provider overwrites it, per-call metadata overwrites that.

Testing

• Tested locally
• make test passes