Raid Frames: suppress intermediate relayouts while retargeting the flat header

[dfrisone]

The bug

Changing raid frame growth direction left frames anchored wrong until a reload.

Cause

_LayoutGroupsImpl retargets the flat header by writing point, xOffset,
yOffset and columnAnchorPoint one at a time. Each write fires
SecureGroupHeader_OnAttributeChanged, which relayouts every visible child
immediately, so the header relayouts three times on the way to the state we
want. The pass that has already taken the new point but not yet the new
columnAnchorPoint can leave both the old and the new point sitting on column
starts, and that intermediate result is what survived.

Fix

Set the header's _ignore for the run of writes and restore the previous value
afterwards, so the Hide()/Show() immediately below rebuilds once from the
complete layout instead of three times from partial ones. This is Blizzard's own
idiom: setAttributesWithoutResponse in SecureGroupHeaders.lua brackets a
group of header attribute writes exactly this way, and
SecureGroupHeader_OnAttributeChanged bails on _ignore at its first line.

Seven lines, one file, no new settings.

Acceptance criteria

• Zero cost unless enabled - no new setting; the code runs only where the
  header was already being retargeted.
• Zero behaviour change without opt-in - the end state of every attribute is
  identical, only the number of intermediate relayouts changes.
• Low cost when enabled - strictly cheaper: two SetAttribute calls replace
  two full child relayout passes.
• Zero taint risk - _LayoutGroupsImpl returns early under
  InCombatLockdown(), so no attribute write here can reach a header in combat.
• Both clients - _ignore is long-standing SecureGroupHeaders behaviour,
  not a new API.

Testing

Confirmed fixed in game by the original reporter on 9.1.7. Growth direction
changes now settle in one pass with no reload.

Known gap, deliberately not widened

The per-group path (8 separated headers, same file) writes point, xOffset
and yOffset through the same unbracketed idiom. It does not write
columnAnchorPoint, so the specific old-and-new-point interaction above cannot
arise there and nothing has been reported against it. Left alone rather than
changed speculatively; happy to bracket it too if you would rather have the two
paths symmetric.