feat: configurable colour-coding/alert thresholds

[nagayon-935]

Summary

Externalises the previously hardcoded RTT / Jitter / Loss colour boundaries into a configurable ui.Thresholds value, settable via CLI flags or the YAML hosts file. warn is the orange boundary, crit the red boundary — the same values that drive the Loss Ratio / RTT / Jitter column colours and the Log-pane alert entries.

Default behaviour is unchanged — every default equals the prior constant (RTT 50/200 ms, Jitter 10/50 ms, Loss 20/80 %).

Changes

• internal/ui/thresholds.go — new Thresholds type with DefaultThresholds() and Validate() (enforces warn < crit and sane ranges). Package-level activeThresholds applied once at Run() startup (TUI renders single-threaded → no locking needed).
• RunOptions.Thresholds threads config into the TUI; tui_helpers.go / mtr_view.go colour functions now read activeThresholds.
• CLI flags — --rtt-warn/--rtt-crit, --jitter-warn/--jitter-crit, --loss-warn/--loss-crit.
• YAML — thresholds: block; CLI flags override YAML values per-field.
• Validation at startup and on YAML hot-reload (validateHostsDoc).
• README.md / README.ja.md — Options table, usage example, hosts.yaml block, colour-coding notes.

Design note

Color helpers are package-level and called from many render sites, so thresholds are stored in a package var set once at startup rather than threaded through every signature — minimal, low-risk diff. Tests swap activeThresholds to verify custom-threshold colouring.

Test plan

• go build ./..., go vet ./...
• go test ./... -race (all packages green)
• Thresholds.Validate() table-driven (warn≥crit, out-of-range, zero)
• Colour functions return expected colours under custom thresholds
• Flag defaults, flag→Thresholds mapping, YAML→cfg, flag-overrides-YAML precedence
• Reload validation rejects invalid thresholds: block
• Manual: run mping --rtt-warn 30 --rtt-crit 100 google.com and confirm colours shift at new boundaries