Add severity-aware exit codes to traffic_ctl

[brbzull0]

Draft pr to follow up #13022

Emit a severity field in JSONRPC error data entries and add an --error-level flag to traffic_ctl so operators can control which annotation severities cause a non-zero exit code.

Summary

• Add a severity field to every JSONRPC error data entry on the wire. Handlers that set
  explicit severity (e.g. ERRATA_WARN) have it propagated; annotations without explicit
  severity default to DIAG (0).
• Add --error-level (-e) flag to traffic_ctl. It sets the minimum severity threshold
  that causes exit code 2. Default is error, preserving current behavior for handlers
  that don't set severity.
• Protocol-level JSONRPC errors (e.g. "Method not found") and errors with no data entries
  always exit 2 regardless of --error-level.

Motivation

Previously traffic_ctl exited 2 for any server error, even informational messages like
"Server already draining." This made it impossible for scripts to distinguish warnings from
real failures. With --error-level, operators can tune the threshold (e.g. --error-level=warn
to treat warnings as errors, or --error-level=fatal to only fail on fatal conditions).

Wire format change

Each entry in the JSONRPC error data array now includes a severity integer:

{"code": 9999, "severity": 4, "message": "Server already draining."}
               ^ new

Usage examples

# Default: annotations without explicit severity default to DIAG.
# DIAG < ERROR, so exit 0.
$ traffic_ctl server drain   # "already draining" is DIAG
$ echo $?
0

# Treat any annotation (including DIAG) as an error
$ traffic_ctl --error-level=diag server drain
$ echo $?
2

# Only fail on fatal or above
$ traffic_ctl --error-level=fatal server drain
$ echo $?
0