Cleanup, and fix, group index handling during ALTER

Two large issues:
- A single "affected" list and it wasn't clear *how* the GI was affected
    - As a result, multiple places were computing the affect
- If a GI wasn't "affected" it would get maintained anyway, needlessly
    - This doubled the per-GI entry counter incorrectly (!)
    - Is a waste to maintain it at all

Apologies for the large diff. The individual commits are more concise:
- A bit of cleanup, shuffling private classes and methods around for reuse
- Add a helper/consolidation struct for all the data that the ALTER flow passes around
- Allow specification of GIs to maintain during writeRow, just like table indexes
- Split the "affected" list into dropped, metadata only and data

These changes allow all the two major issues to be fixed, along with quite a bit of consolidation and cleanup.

Note that this *explicitly*, instead of accidentally, causes GIs to be maintained during the row writes. Only if needed, as unaffected ones are skipped. I think this is preferable to building after the fact (simpler and uniform), especially in the online world, but would be open to discussion.

This merge is halfway to the changes I alluded to yesterday. It would be ideal to not have to drop and recreate at all, by handling GIs in SchemaManager#alterTableDefinitions, but that is a (subtly) large change. I'm to blame for that, but would like to defer it now as it isn't strictly required for the online DDL work.