feat: Add abrSwitchInterval config option

[christriants]

This PR will...

Add support for a new config option, abrSwitchInterval, which allows users to specify a minimum amount of time (in seconds) between automatic ABR-initiated level switches.

Why is this Pull Request needed?

Existing ABR configuration options tune bandwidth-estimation sensitivity but do not provide any control over how frequently level switches occur.

abrSwitchInterval introduces explicit switch-level throttling. This enables:

1. More stable playback quality without reducing ABR responsiveness
2. A separation between detection (bandwidth estimation) and action (switching)
3. Alignment with industry practices (e.g., Shaka Player’s switchInterval)

This gives applications finer control over playback stability while preserving fast and accurate network adaptation.

Are there any points in the code the reviewer needs to double check?

1. Throttling logic in level-controller.ts:
   The cooldown is enforced in set nextLoadLevel() using performance.now() timestamps. Review the time comparison and edge-case handling. Debug logs are included to trace allowed vs. suppressed switches.

2. Emergency downswitch behavior:
   Confirm that emergency downswitches triggered via AbrController._abandonRulesCheck() still flow through nextLoadLevel and are throttled (or intentionally exempt, depending on desired behavior).

3. Manual to ABR mode transition:
   After switching from manual mode back to ABR mode, confirm the first ABR switch correctly resets or respects lastABRSwitchTime. Tests cover this partially, but code should be reviewed for any subtle timing interactions.

4. Placement of throttling logic in level-controller:
   Throttling is implemented in nextLoadLevel() rather than abr-controller. This ensures all ABR-initiated level changes are subject to the cooldown, including emergency downswitches, playlist-driven changes, and any future controllers that update nextAutoLevel.

Resolves issues:

Resolves this feature request: #7385

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[hongjun-bae]

Good work.