Assign suffix to changes fetched from the database.

This is so that `revert` will find the correct script for reworked changes.
There might be an argument to be made that this should also come from the
database, but since the suffix comes from a tag, and the tag may have been
changed, this seems safer. Besides, if the change is not in the plan, is the
revert script going to be present, either?

OTOH, maybe it would be better, should it come up in the future, to store the
ID of the previous version of a change, and when we see that, find the
previous version of the change, then the first tag after that change, and
assign the suffix. This would allow it to use the same suffix as was present
when the reworked change was deployed.

Either way, the tag could have been changed, which will cause no end to
confusion. This was the simpler fix for now. Will revisit in the future if it
becomes a problem.

Closes #67.