Pluggable host-side logger interface #1434

Description

Add a pluggable logger interface so frameworks integrating Warp can route its host-side diagnostic output through their own logging machinery instead of print() to stdout.

Proposed public surface:

• wp.Logger — runtime-checkable Protocol with debug, info, warning, error methods. Any object satisfying the interface works.
• wp.set_logger(logger) / wp.get_logger() — install or retrieve the active logger.
• wp.ScopedLogger(logger) — context manager for temporary overrides (mirrors wp.ScopedAllocator).
• wp.utils.LoggerKit — adapter for Omniverse Kit hosts (routes through Carbonite).

Pass None to set_logger() to restore Warp's built-in default. The default implementation is kept internal: only the protocol and entry points above are public, mirroring how the default mempool allocator is internal while the wp.Allocator protocol and wp.utils.AllocatorRmm are public.

Context

Today Warp emits host-side diagnostics through print() and warnings.warn() calls scattered across the codebase, with no extension point. Concrete needs:

• Omniverse Kit integrations need Warp messages to appear in Kit's log viewer with proper severity and source attribution, rather than going to stdout where Kit doesn't see them.
• Anything that wants to capture or redirect Warp's diagnostic output (forwarding to stdlib logging, capturing in tests, framing per-rank in distributed jobs) currently has to scrape stdout.

Complements #1315 (which scopes the underlying warp.utils.warn() filter-override bug). This issue covers the extensibility surface that allows non-default loggers to exist in the first place.