Add native DShot / BDShot telemetry error counters and per-ESC error rate

## Feature request

**Is your feature request related to a problem? Please describe.**

Yes.

When using DShot bidirectional telemetry / BDShot, there is currently no simple built-in way in ArduPilot to monitor the quality of the ESC telemetry link itself.

In practice, this makes troubleshooting difficult:
- One ESC may be losing telemetry frames because of wiring, EMI, timing issues, or ESC firmware compatibility.
- The user may still see partial ESC telemetry, but has no direct indicator of how reliable that telemetry stream actually is.
- This makes it harder to diagnose issues affecting ESC telemetry based features, including RPM-based filtering and general ESC monitoring.

A Betaflight-style "DShot error %" diagnostic would make bench testing and field debugging much easier.

**Describe the solution you'd like**

I would like ArduPilot to add native DShot / BDShot telemetry error monitoring, ideally with per-ESC counters and an exposed error percentage.

Suggested implementation:
- Track, for each ESC:
- total expected telemetry responses,
- valid telemetry responses received,
- invalid / missing / corrupted responses.
- Compute a per-ESC error rate, for example:
- error % = invalid_or_missing / total_expected * 100
- Expose this information through one or more of the following:
- DataFlash logs,
- MAVLink / GCS status,
- Lua scripting bindings,
- optional Mission Planner / GCS display fields.

A Lua-accessible API would be especially useful, for example:
- get total frames,
- get error count,
- get error percentage,
- optionally reset counters for bench testing.

This would allow users to:
- identify a single problematic ESC quickly,
- detect degraded telemetry quality before flight,
- compare ESC link quality after hardware changes,
- create custom Lua warnings or pre-arm checks.

**Describe alternatives you've considered**

The main alternative is to estimate telemetry quality in Lua indirectly, for example by:
- checking whether RPM data is missing,
- detecting frozen telemetry values,
- detecting unexpected zero RPM while motors should be running.

However, this is only an approximation and not a real protocol-level error measurement.
It cannot distinguish cleanly between:
- missing telemetry frames,
- delayed updates,
- valid but stale values,
- real DShot / BDShot reception errors.

Another alternative is to inspect logs manually, but this is much less convenient and does not provide a direct per-ESC reliability metric.

For this reason, native support inside the DShot / ESC telemetry backend would be much more useful than a Lua-only workaround.

### Platform

- [x] All
- [ ] AntennaTracker
- [ ] Copter
- [ ] Plane
- [ ] Rover
- [ ] Submarine

### Additional context

This request is mainly about diagnostics and reliability monitoring.

A practical use case is bench testing:
- spin motors at low throttle,
- observe per-ESC DShot telemetry error rate,
- immediately identify wiring, EMI, or ESC compatibility issues.

Another use case is Lua scripting:
- warn the user if one ESC exceeds a configurable error threshold,
- log persistent telemetry degradation,
- refuse arming if telemetry quality is too poor.

A possible minimal implementation would be:
- internal per-ESC counters in the DShot / ESC telemetry backend,
- read-only access from Lua,
- optional logging of the current error percentage.

Even a basic first version with only:
- total responses expected,
- total valid responses,
- total invalid/missed responses

would already be very valuable.

Thanks !

Start by tracing the DShot / ESC telemetry backend mentioned in the issue and determine how expected, valid, invalid, and missing responses are represented. Review the possible Lua scripting, DataFlash logging, and MAVLink/GCS exposure points, then define a minimal scope whose done state includes per-ESC counters and a usable error-rate metric.

Written by the indexing model from the issue text.