ActionBars: throttle the arg1==0 slot-changed full walk too

[dfrisone]

What does this PR do?

Every other ACTIONBAR_SLOT_CHANGED slot is throttled to ~4/sec with trailing coalescing, but arg1 == 0 ("all slots changed") was explicitly exempted with a comment calling it "rare and always passes." It isn't rare: a loadout manager addon that swaps talents, gear, and an action bar layout together can fire it several times in a burst. Each firing was an unthrottled full walk over every bar and button (~140+), painting texture/desaturation/usable-tint/count/action-text on each one -- with no debounce at all, unlike every other event this dispatcher handles.

This gives arg1 == 0 the same throttle as any other slot, keyed separately (0 is not a real action slot number, so it can't collide with per-slot throttle state). Leading edge still passes immediately; repeats inside the window coalesce into one trailing re-dispatch.

Context

Reported by Embrace on 9.0.7: EllesmereUIActionBars freezing the game for 15-20 seconds when applying a BTWLoadouts loadout (talents + gear + action bar layout together), with Action Bars visibility set to Mouseover or Show When Spellbook Is Open, accompanied by repeated LUA_WARNING: Script from "EllesmereUIActionBars" has exceeded its execution time limit through Blizzard's UpdateAction/OnActionBarSlotChanged.

The full-walk cost this PR throttles is independent of bar visibility mode as far as I can tell from the code, so it should help regardless of visibility setting -- but I have not been able to reproduce the specific Always-vs-Mouseover difference in the report myself. If the freeze persists after this for Mouseover specifically, the visibility/fade recompute path needs its own look.

How was it tested?

Read-verified against the dispatcher's existing per-slot throttle path (same leading-edge/trailing-coalesce shape, reused rather than duplicated) and syntax/style checked. Not yet reproduced or retested in-game against the original report.

Checklist

• New settings default OFF (no behavior change without opt-in) -- N/A, no new settings
• Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built -- N/A, this only changes the throttle window on an existing always-on event handler
• Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations) -- reuses the existing per-slot throttle tables under one extra key; no new timers beyond the existing coalescing pattern
• No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames -- N/A, this only changes when EllesmereUI's own dispatcher re-enters itself
• Tested in-game on live; no version gates or pre-Midnight APIs added -- not yet reproduced against the original report, see note above