Adding a tag can bork reworked changes

[theory]

One cannot currently add a tag to the middle of a plan, but such is planned in the future. In the meantime, a tag could be added manually. Either way, this could bork reworked changes, because they rely on the name of the last tag before the reworking change to determine the suffix to use for their script names.

Consider a plan like this:

foo
bar
baz
@alpha

woot
bar

When this plan is parsed, the first bar will be assigned the suffix @alpha, so the script names should be named bar@alpha.sql. So far so good. But consider what happens if we were to add a second tag after woot:

foo
bar
baz
@alpha

woot
@beta
bar

When this plan is parsed, the first bar will be assigned the suffix @beta. Naturally, this means that its scripts, which were all previously named with the suffix @alpha, wont' be findable.

I can think of a few ways to deal with this, none ideal:

• Never add support for tagging anywhere other than at the current end of the plan. I don't think this will fly, and as I said, one could insert a tag manually.
• Rename the files if the suffix changes. This would allow us to add support for tagging an arbitrary change, but won't help the case where the tag was added manually. Besides, if the files were to be re-named, the VCS would not be aware of that (at least until Add VCS Integration #25 was completed), so the user would have to make sure to mark them as renamed and commit accordingly. This is annoying.
• Record all intervening tags in the reworked change and search for the first one with matching files. This will require stating quite a bit, but I think that's reasonable.

Seems like the third option is the only one that would really be transparent and DWIMy. It would require that such possible suffixes be appended to the reworked changes both when parsing the plan and when loading from the database, which is annoying but do-able.