tIED: removeIeds behaviours with empty SubNetwork/Communication

[stee-re]

When using removeIED to remove IEDs, the function correctly removes ConnectedAP elements belonging to the
removed IED. However, if the removed IED held the last ConnectedAP in a SubNetwork, the SubNetwork is left
with no ConnectedAP children — which is a schema violation.

For example, given:

 <Communication>
   <SubNetwork name="StationBus" type="8-MMS">
     <BitRate unit="b/s" multiplier="M">100</BitRate>
     <ConnectedAP iedName="IED_A" apName="AP1"/>
   </SubNetwork>
 </Communication>

After calling removeIED for IED_A, the result is:

 <Communication>
   <SubNetwork name="StationBus" type="8-MMS">
     <BitRate unit="b/s" multiplier="M">100</BitRate>
   </SubNetwork>
 </Communication>

The SCL schema requires SubNetwork to have at least one ConnectedAP child, so this produces:

 Missing child element(s). Expected is ( {http://www.iec.ch/61850/2003/SCL}ConnectedAP ).

This is easy to hit when using a bulk-remove workflow (e.g. the Remove IEDs plugin) where all IEDs on a
SubNetwork are removed.

What should the behaviour be here?

The obvious fix might be to remove the empty SubNetwork (and cascade to Communication if all SubNetworks are
gone), but this has a significant downside: removing a SubNetwork also removes its child configuration like
BitRate, Text, Private elements, and desc/type attributes — none of which are related to the IED being
removed. The user asked to remove an IED but unrelated network configuration gets caught in the crossfire,
which amounts to data loss.

An alternative approach, similar to how LNode references are handled, would be to retain the last ConnectedAP
with iedName="None" (keeping the original apName intact, since apName has a minLength=1 restriction and
cannot be empty). This preserves the SubNetwork structure and its configuration while clearly indicating the
access point reference is unbound.

A third consideration: when multiple IEDs share a SubNetwork and are removed, several of them may have had
ConnectedAPs with identical apName values. Would there be any value in removing duplicate ConnectedAPs (same
apName, both now iedName="None") while retaining one, similar to the deduplication approach for LNodes in
#121?

Options (so far):

1. Remove the empty SubNetwork (and Communication if all SubNetworks are gone) — simple but risks data loss
   of unrelated SubNetwork configuration.
2. Retain the last ConnectedAP with iedName="None" — preserves SubNetwork structure, mirrors the LNode
   pattern, avoids data loss. Here we just leave the apName as is - knowing it will be updated when an IED is re-attached.
3. Option 2 + deduplicate — additionally remove ConnectedAPs that would become duplicates (same apName,
   iedName="None"), keeping only one per unique apName.

What would be the preferred behaviour? Happy to prepare a PR once there's agreement on the approach.

This is kinda related: #121 (similar issue with LNode handling during IED removal)