feat: Add Linux syslog backend for mw::log LogMode::kSystem

[btirunagaru]

Feature Request / Modification Description

Add a Linux syslog mw::log backend that fills the LogMode::kSystem slot
on Linux (HGY aarch64 and x86 host), mirroring the existing QNX slog
backend exactly.

Today LogMode::kSystem is only served on QNX (via the slog backend in
score/mw/log/backend). On Linux there is no system-logging backend at
all, so mw::log consumers configured for LogMode::kSystem silently get
no output on Linux/HGY targets. slog is target_compatible_with os:qnx
and this new backend is target_compatible_with os:linux, so exactly
one compiles per build and both safely share the same kSystem slot
without any LogMode/dispatch changes.

Scope of this request:

• score/mw/log/detail/syslog/syslog_backend.{h,cpp}: SyslogBackend, a
  Backend implementation whose FlushSlot formats "appid,ctxid: payload"
  and forwards to score::os::Syslog::syslog() at a severity mapped from
  mw::log's LogLevel (kFatal->LOG_CRIT, kError->LOG_ERR,
  kWarn->LOG_WARNING, kInfo->LOG_INFO, kDebug/kVerbose->LOG_DEBUG);
  Init() calls openlog(app_id, LOG_PID|LOG_NDELAY, LOG_USER).
• score/mw/log/detail/syslog/syslog_recorder_factory.{h,cpp}: CRTP
  SyslogRecorderFactory wiring a TextRecorder over SyslogBackend, using
  score::os::Syslog::Default() for the real OS wrapper.
• Unit tests for both, against @score_baselibs//score/os/mocklib:syslog_mock.
• score/mw/log/backend/syslog_registrant.cpp: registers
  CreateSyslogRecorder against LogMode::kSystem via BackendRegistrant,
  mirroring slog_registrant.cpp.
• BUILD wiring: new syslog cc_library (target_compatible_with os:linux,
  alwayslink), plus the detail/syslog BUILD.

Depends on: eclipse-score/baselibs#501 (Add Linux syslog(3) OS wrapper — score::os::Syslog)

No new formal Stakeholder/Tool Requirements are introduced — the design
reuses the existing Backend/BackendRegistrant/LogRecorderFactory
extension points already used by the QNX slog backend; no LogMode or
dispatch changes are needed.

Expected Changes of work products

• Requirements
• Architecture
• Safety Analysis
• Security Analysis
• Detailed Design
• Implementation and Testing
• all

Impact analysis

1. Type of Change Request
   New Feature/Component — adds a new backend implementation for the
   existing LogMode::kSystem slot. No change to LogMode or dispatch
   logic.

2. Dependencies on other Change Requests
   Depends on the companion baselibs feature request "Add Linux
   syslog(3) OS wrapper (score::os::Syslog)"
   (@score_baselibs//score/os:syslog) — link that issue here once filed.

3. Estimates for Realization

• Work products modified: score/mw/log/backend/BUILD (additive
  cc_library) plus new syslog_registrant.cpp; new
  score/mw/log/detail/syslog/* sources, headers, tests, and BUILD.
• Verification: new unit tests (syslog_backend_test.cpp,
  syslog_recorder_factory_test.cpp) against
  @score_baselibs//score/os/mocklib:syslog_mock, covering log-level to
  syslog-priority mapping, app/ctx id truncation to 4 chars, empty
  payload handling, and slot reservation/overflow behavior.
• Effort/resources/risk: small, low risk. Purely additive backend
  plugin, selected only via LogMode::kSystem + target_compatible_with
  linux; existing slog (QNX) and other backends are untouched.
• Stakeholders: logging component owners (CODEOWNERS: score/mw/log).
• Milestones: single implementation PR, no phased rollout.

4. Potential Impact on the platform
   None on existing platforms. target_compatible_with
   @platforms//os:linux, registers only against LogMode::kSystem. slog
   (target_compatible_with os:qnx) continues to be selected unchanged on
   QNX — exactly one of the two backends compiles per build, so there is
   no dual-registration or ambiguity risk.

5. Potential Impact on Security
   Minimal. Writes app id / context id / payload strings to the local
   syslog daemon via openlog/syslog(3) — the same trust boundary already
   crossed by the existing QNX slog backend. No new external interface
   and no additional untrusted-input handling is introduced.

6. Potential Impact on Safety
   None. QM classified. Mirrors the design of the already-accepted QNX
   slog backend (Backend / BackendRegistrant / LogRecorderFactory
   extension points); log delivery to syslog is best-effort, same as the
   existing slog path — no safety-relevant behavior depends on it.
   Expected ASIL level: QM.

7. License Impact
   None. New files use the standard Apache-2.0 SPDX header already used
   throughout the repository; no third-party code is introduced.

Safety or Security relevance

• none
• Safety relevant
• Security relevant

Expected required ASIL classification

QM

Expected Implementation Version (Release)

1.0