Proposal: Extend log crate with contextual, typed, and fatal-level logging

Motivation: Automotive Use Case

1. Contextual / Hierarchical Logging

• Current target (module path) is too flat for complex automotive applications where multiple layers/modules may reuse common subsystems.
• Developers need to distinguish who logged what not only by module but also by parent/ancestor context.
• Add optional hierarchical context (e.g. ECU → Subsystem → Component).
• Such context could be attached automatically (per logger instance) and optionally extended by the user.
• Enables better traceability of log origins in safety-critical systems.

2. Type-Aware Logging

• Today everything is stringified, discarding type info needed by automotive backends (e.g. DLT expects type fidelity: numeric vs string vs struct).
• Proposal: allow passing typed values directly (info!(42), info!("user_id" = 43), info!(User { id: 7 })).
• Preserves fidelity for DLT and similar tools, enables filtering/sorting, while staying backward-compatible and simple for developers.

3. Fatal Log Level

• Current Error conflates recoverable and unrecoverable failures.
• Add a Fatal level for logging critical, fail-stop conditions.
• Essential for automotive where safety hazards must be identified and escalated distinctly.

Benefits

• Improves interoperability with standards (e.g. DLT, AUTOSAR logging).
• Strengthens suitability for safety-critical domains (ISO 26262 compliance).
• Still lightweight: could be added as opt-in features, maintaining compatibility.

Start by reviewing the current logging levels, module-path targets, and info! usage described in the proposal. Define the scope and compatibility requirements for hierarchical context, typed values, and a fatal level; done requires an agreed design covering all three areas before implementation begins.