refactoring map_storage and sinopia_maps

[briesenberg07]

which will most likely never happen, but I'd still like to note some of the most significant

🎯 Areas for improvement/things I'd change

• matching works differently for guidance_sets (by guidance_set child element, using whole RT ID as repeatable attribute value) and for implementation_sets (by entire implementation_set element, matching on RT ID components entered as values for distinct elements)
• For source/storage data (currently XML prop_set_* instances)--
  • don't start with lists of RDA/RDF elements--we won't use most of them!
  • write code to populate .xsd or other validation tool so that property information can be added as needed
• Related to the above, PTs with multiple property options are used heavily. Implementing individual properties in the templates is happening less at this point than implementing a PT (which could be independent of any particular property) and listing the desired property options... however, the RDA property relationships and polyhierarchy is important to RT design...

CC @cspayne in case you have thoughts and would like to pitch them in!

[briesenberg07]

more known issues

• unnecessary validation errors in prop_set_uwRdaExtension.xml because there is no uwsinopia:toolkit \@url for UW properties
• as above, matching works differently for guidance_set/* elements than for implementation_sets. Currently, guidance_set child elements can only match to one RT ID, or multiple using @rt_id="defalut", but more than one specific RT ID can't be indicated for matching. This can be validated in .xsd, but could this be processed when an RT ID needs to be removed (the guidance_set child element will no longer be used for the RT)?