Require ClassicAPI v1.15.0

An out-of-date ClassicAPI did not degrade the addon, it decapitated it.
Utility.lua calls ev:RegisterUnitEvent at file scope (v1.15.0), so on an
older build that call raises and Lua abandons the rest of the chunk --
every definition below line 4118 of a 10040-line file, some 6000 lines,
silently never happens. What the user sees is the first one a common path
reaches: PLAYER_TARGET_CHANGED calling a nil ClearResistState, once per
target swap, forever.

The requirement check still said v1.12.1 (the positional
C_UnitAuras.UnitAura), so the affected client sailed through it and the
warning it did print promised only that "dispel-type conditionals will be
unavailable" -- describing a graceful degradation that was not happening.
The gate is now v1.15.0 and says the addon cannot finish loading, with the
installed version in the message the way the Nampower branch does it.
ClassicAPI.lua gains GetVersion() to decode CLASSIC_API_VERSION, keeping
the X*10000 + Y*100 + Z encoding inside that module, and its header notes
that the minimum has to rise with any ClassicAPI call adopted at file
scope -- that is the property that turns a version mismatch into a silent
half-load rather than a missing feature.

C_Macro.SetMacroDisplay also ships in v1.15.0, which retires the last
pre-ClassicAPI display path:

  useClassicAPIDisplay folds into ClassicAPIMacroDisplay. The two were
  always equal -- set together at load, cleared together in
  ReleaseDisplays -- and one of them is a handshake ClassicAPI reads, so
  a second name for the same state could only ever drift.

  TestForAllActiveActions loses the per-slot ACTIONBAR_SLOT_CHANGED
  fan-out. Publishing repaints every slot holding the macro through the
  client's own notifier; the fan-out was what ran when SetMacroDisplay
  was unavailable, and its one remaining reachable state was after
  DisableAddon, where ReleaseDisplays has already handed all 36 macros
  back and ClassicAPI repaints them itself.

The load-time feature detect stays, with a new reason: below the minimum
the addon is already broken, so a nil SetMacroDisplay now means ClassicAPI
is absent outright -- the case the requirement check warns about and then
keeps running.

Init.lua

@@ -29,14 +29,17 @@ CleveRoids.supported   = CleveRoids.hasTurtle
 -- tooltip, cooldown sweep, range and usable state all come from the client -- including
 -- the drag cursor and the macro window grid, which Lua cannot reach.
 --
--- Feature-detect rather than version-check: the API is unreleased, so
--- CLASSIC_API_VERSION reports the dev sentinel. ClassicAPI stands down from macro
--- display entirely when it sees this addon loaded; ClassicAPIMacroDisplay is what
--- tells it we drive it instead. A fork that leaves the flag unset keeps the old
--- behavior -- both must never drive the same buttons.
-CleveRoids.useClassicAPIDisplay =
+-- ClassicAPI stands down from macro display entirely when it sees this addon loaded;
+-- ClassicAPIMacroDisplay is what tells it we drive it instead, and ReleaseDisplays
+-- clears it to hand every macro back. A fork that leaves the flag unset keeps the old
+-- behavior -- both must never drive the same buttons. It doubles as the internal
+-- "may we call C_Macro.SetMacroDisplay" guard, so the two can never disagree.
+--
+-- Feature-detect rather than version-check: SetMacroDisplay ships in ClassicAPI
+-- v1.15.0, this addon's minimum, so a nil here means the client mod is missing
+-- outright -- the case Core.lua's requirement check warns about but keeps running.
+CleveRoids.ClassicAPIMacroDisplay =
     (type(C_Macro) == "table" and C_Macro.SetMacroDisplay ~= nil) and true or false
-CleveRoids.ClassicAPIMacroDisplay = CleveRoids.useClassicAPIDisplay
 
 CleveRoids.ParsedMsg = {}
 CleveRoids.ExpandedGroups = {}