PDME — PDM RTF issue: "successor"

As documented in 2.4.3.20, Supersedes is a RevisionMaster relationship that represents the decision to "roll part number" in
implementing a part revision. That is, it represents the replacement of a previous rev, e.g. 1234-C-1, with a new Part, e.g.
1255(-A-1). But the most common RevisionRelationship, also sometimes called "supersedes", is what happens when 1234-D replaces
1234-C. That relationship is actually modelled by the relationship called "successor" that is a documented subtype of "Derive"
(2.4.3.17), and is a relationship between ItemIterations (which is correct). But the other subtypes of Derive ("copied" and
"translated") have significantly different semantics, implying a continuing dependency on the original. Successor, especially
as it relates to ECNs, does not implicitly have this property: 1234-D-3 may be the new baseline, successor to 1234-C-4.
Successor should be an explicit subtype of IterationRelationship (at the same level of visibility as Dependency and Derive) in
the PdmFramework.

Note for the RTF: I am raising this as an issue to be discussed, but I'm not convinced we want to make a change. First, this
change could be disruptive to existing implementations. Second, if you have a base part design pending approval and start a set
of serial-number-specific variants of the base part (truly "derived" iterations) and the base part design is not approved and
acquires a "successor", you want to retrofit the changes in the base part (the "successor") to the variants. And that is a
"convenience function" that follows the "successor" relationship backward and then the transitive closure of the Derive
relationships forward, including successor iterations of the derivative variants. I assume that is why the model works the way
it does. It may be that the ECO/ECN "successor"/"supersedes" relationship is actually a different relationship!