Add configurable KVP client API and harden concurrent telemetry writes

[peytonr18]

Summary

Expands KVP telemetry beyond the original event-prefix change by introducing a public, external-caller-friendly KVP client API, while strengthening concurrency behavior for startup truncation and documenting the end-to-end design.

This enables multiple emitters/libraries to coexist more safely and gives callers explicit control over KVP emission lifecycle and identity.

Changes

New public KVP client API (kvp.rs, re-exported via logging.rs)

• Added KvpOptions with builder-style configuration:
  • vm_id
  • event_prefix
  • file_path
  • truncate_on_start
• Added Kvp::new() (default options path).
• Added Kvp::with_options(...) for explicit caller configuration.
• Added direct emission APIs:
  • emit(message, level)
  • emit_health_report(report)
• Added close().await for graceful shutdown and queue drain.

Internal wiring updates (logging.rs)

• setup_layers continues to use tracing-layer emission internally.
• Internal construction now goes through Kvp::new_internal(...) with explicit options-derived inputs.
• Existing azure-init tracing behavior remains intact.

Concurrency hardening for startup truncation (kvp.rs)

• Truncation path now uses file locking to avoid check-then-truncate races.
• Lock contention during truncation is treated as non-fatal (expected in multi-client environments), allowing initialization to continue safely.

Breaking Changes

This PR intentionally changes the public KVP API shape:

• Removed old subscriber-wrapper usage pattern (Kvp<S>::new(...), .layer(), .halt()).
• Replaced with direct client API (Kvp::new/with_options, emit, emit_health_report, close).

Goal

• Make KVP emission straightforward for external callers without requiring tracing_subscriber plumbing.
• Support concurrent/multi-emitter scenarios more safely.
• Keep internal azure-init tracing integration while exposing a cleaner public surface.

Resolves #239

[cadejacobson]

This looks awesome to me! Good work

[anhvoms]

if this is expected (that only one client is expected to do the truncation), this should not be an error. We can easily conclude an error situation by seeing all clients failing, but no successful truncation (from the log a few lines below)

[anhvoms]

I think we want to document that KVPs emitted after health report (emit_health_report) are not collected by Azure platform today.

It might be helpful to show a bit more complicated example like emit an in-progress provisioning, call a function foo, then emit a report failure on foo's failure; otherwise emit a success