Split g7:SLGC-STAT and g7:SLGS-STAT from g7:ord-STAT

[dthaler]

Per GEDCOM Steering Committee discussion on
FamilySearch/GEDCOM.io#106

Note that this does not affect what is permitted in GEDCOM, it just improves the ability of tools to validate what is permitted.

[tychonievich]

This PR implies a change in policy that should apply in several places if it is applied at all.

Current policy: enumsets (and the structure types that use them as payloads) may span several closely related concepts. We rely on humans to understand that some combinations are nonsensical, just as we do for things like acyclic individual/family links, not ALIA yourself, not having a EMAIL for people who died before the 1980s, etc.

Proposed policy: all enumset values should be valid in the context in which they are allowed. This would require changing at least three enumsets:

• g7:enumset-EVEN (7.1 changes this to g7:enumset-NO) has both FAM and INDI values, but they're not both valid in the same contexts. Fixing this would require making both g7:INDI-NO and g7:FAM-NO structures (and with 7.1 also g7:NAME-NO too)
• g7:enumset-ROLE has a variety of roles, not all of which make sense in all contexts. For an INDI.ASSO.ROLE the values CLERGY, OFFICIATOR, and WITN don't make sense; for event.ASSO.ROLE the value MULTIPLE doesn't make sense.
• g7:enumset-ord-STAT has several versions, discussed in this pull request

My vote is to not change any of these. But I don't feel strongly about that: if we want to split the enumsets (and in some cases the structure type that holds them) I'm OK with that, as long as we do it in a consistent way. We do need to think about the impact of such a change on existing extensions and so on, though: if I've added an extension element to a current enumset and then it is changed, I have to update my extension to match. I'm not sure it's worth that cost, but if it ever is than the sooner the better.

[dthaler]

Discussion in GEDCOM Steering Group:
Move to next-major. The constraint wasn't in 7.0 until 7.0.10 which says "applies to" which is not defined. Luther will file an issue to clarify it's a recommendation not a requirement.