Labels need to be replaced when the superevent's preferred event changes

During a discussion of outstanding questions [1], @deep.chatterjee, @erik-katsavounidis, @shaon.ghosh, @shasvath.kapadia and I identified some issues stemming from my discussion with @leo-singer here !290 (comment 66343). Let's start with a scenario described by Leo, in that comment:

I don't think that this makes sense. Consider the following scenario. A pipeline that uses ungated h(t) uploads an event that is the initial preferred event of a new superevent. There is a glitch, and so the superevent is vetoed. Then another pipeline that uses gated h(t) uploads an event that becomes the new preferred event. The glitch was excised from the gated h(t), so an alert should go out in this case. However, the superevent has already been vetoed, so no alert is sent.

In our call, we elaborated on this scenario and identified some issues. As an example, let's call the original preferred event $ORIG, and the new preferred event $NEW. When the superevent $SUP is created, it copies skymaps and EM bright data from $ORIG, and runs DQ checks and P(astro), if applicable, on $SUP. Then, $NEW comes in with a higher significance, and is adopted as the new preferred event for $SUP. Now, if $NEW uses a different gated h(t) configuration from $ORIG, it's likely that the DQ information initially calculated for $ORIG will no longer be valid and should be replaced with DQ information calculated for $NEW. Then, a DQV from $ORIG should no longer apply to $SUP.

When a superevent's preferred event is changed, the existing superevents' labels should be wiped and copied from the new preferred event. To preserve the information that $ORIG was vetoed, we need to copy the superevent's labels to the $ORIG event before the wipe.

[1] starting on sheet "O3 detail", line 122 here https://docs.google.com/spreadsheets/d/1kLO84LNSj6B_PTlB35ujh-uYxXLdFc7L4P2lxY1-KXc/edit#gid=1860743627