Strat names with multiple parents

[davenquinn]

child_id	parent_id	parent_strat_name	child_strat_name
1712	69357, 9927	Bighorn Gp, Big Horn Gp	Red River Fm
4092	4768, 10269	Newark SGp, Chatham Gp	Gettysburg Fm
5012	8291, 71714	Interlake Gp, Interlake Gp	Cedar Lake Fm
60687	60364, 66539, 76952	Basher Kill Tongue Mbr, Wurtsboro Tongue Mbr, Lucy School Siltstone Mbr	Bloomsburg Red Beds Bed
64337	63459, 63302	Laura Lake Mafic Complex SGp, Kellogg Creek Mafic Complex SGp	New Georgia Gp
66418	60029, 60998, 77531, 61160, 60054, 79808, 77265, 76430, 60487	Agamenticus Complex SGp, Burnt Meadow Complex SGp, Pawtuckaway Complex SGp, Cape Neddick Complex SGp, Alfred Complex SGp, Tatnic Complex SGp, Mount Tripyramid Complex SGp, Hart Ledge Complex SGp, Belknap Mountain Complex SGp	White Mountain PlutonicVolcanic Suite Gp
80846	85051, 85051	Woodbine Gp, Woodbine Gp	Bassett Fm

We currently have seven cases where the strat_tree table contains multiple parents for a single child. There are a few duplications, but others appear to be hierarchy inversions relative to what is assigned in GeoLex. This appears to arise in a few cases when the suffix of a unit implies a lower hierarchy level than the actual relationship (e.g., various "Complexes" which are contained within the "White Mountain Plutonic Suite").

We should fix these instances, but should multiple parents per child be allowed at all? That adds significant complexity and potential for dangling edges to the hierarchy navigation code.

[davenquinn]

The Gettysburg Formation is an interesting case that might argue for keeping the ability to have multiple parents. But this could also be solved by two entities linked to the same concept.

[davenquinn]

This is related to #231 (where we are uncovering some of these issues by reworking rebuild scripts) and slightly to #228.