Do not generate invalid content or config definitions when adding new SNS nodes

When adding a new same-named-sibling to either config or content, there can be a bad interaction with LocationMapper rules that lead to invalid config or content definitions being generated by auto-export. This leads to an invalid state on disk, which causes auto-export to fail and causes a repo restart to fail at bootstrap.

Bad cases for config:

1. If a new node path contains an index, and LocationMapper indicates that this node should be placed in a new file, the rule against using an index in a root definition path leads to a root definition path of the parent node. There may already be a root definition path for the same node, which causes a conflict and validation error when the module is reloaded.
2. ... To be continued

Bad cases for content:

1. If a LocationMapper rule puts a child node in a new file, and a new SNS for that node is added, we need to add a new file with a root path containing an index. There is no way to generate this content definition without either failing a validation rule or changing the transactional guarantees for existing content.

The conclusion that Ate and I have come to is that we must relax the restriction on definition root paths to allow SNS indices. This has the consequence that any operation that works with a root definition path (e.g. sorting definitions for processing order) must handle SNS indices correctly, including sort order for indices > 9. That implies some form of splitting/parsing of path segments and indices, custom sorting rules, etc.

For now, we're also bumping down the priority of this item. This will only occur in practice if a developer performs a console operation that bypasses existing checks in the CMS that prevent SNS in content folders and gallery folders. This should be a rare and preventable action with fairly obvious workarounds, e.g. change node names to avoid SNS collisions.