Should abort if conflicting gc-tag is detected

[Angus Lees]

If there is an existing object with the wrong gc-tag, then this most likely indicates either a misunderstanding of the gc-tag, or a hazardous conflict with someone else's kubecfg pipeline.

I think it would be reasonable to abort (by default) if a conflicting gc-tag is detected as the update is proceeding, with a suitably explanatory error message. It needs to be possible to optionally weaken this to a warning so that legitimate use cases remain possible (eg: renaming the gc-tag, adopting resources created from an abandoned kubecfg pipeline).