High: CIB: no schema violating oversimplified patching with @id-ref

Previously, this input to modification of CIB:

<primitive ...>

<operations>
  <op id="mySmartFuse-monitor-outputpower" name="monitor" interval="2s">
    <instance_attributes id="mySmartFuse-outputpower-instanceparams">
      <nvpair id="mySmartFuse-outputpower-req" name="req" value="outputpower"/>
    </instance_attributes>
  </op>
</operations>
<instance_attributes id="mySmartFuse-params">
  <nvpair id="mySmartFuse-params-ip" name="ip" value="192.0.2.10"/>
</instance_attributes>
<instance_attributes id-ref="mySmartFuse-outputpower-instanceparams"/>

</primitive>

would degenerate into this:

<primitive ...>

<operations>
  <op id="mySmartFuse-monitor-outputpower" name="monitor" interval="2s">
    <instance_attributes id="mySmartFuse-outputpower-instanceparams">
      <nvpair id="mySmartFuse-outputpower-req" name="req" value="outputpower"/>
    </instance_attributes>
  </op>
</operations>
<instance_attributes id="mySmartFuse-params" id-ref="mySmartFuse-outputpower-instanceparams>
  <nvpair id="mySmartFuse-params-ip" name="ip" value="192.0.2.10"/>
</instance_attributes>

</primitive>

apparently resulting in an invalid configuration instance
(cannot mix @id-ref with anything else incl. @id).

Now, we are more careful about @id-ref so this won't happen.
There's a slight time complexity penalty in case we search the
matching element with identical @id-ref specification that we
could skip, resulting in multiple identical siblings with these
elements, but let's stick with absolute idempotency, as it seems
to be quite a hit.