Investigate options to ensure (physical-)store-unique content URLs

[AFaust]

While implementing the "Selector Property" store it has come to my attention that there are some serious restrictions to orphan cleanup / cleanup on migration rollback when using this store (as well as the Enterprise equivalent of it).

• content URLs are not unique based on the store they are located in as physical files
• content moved from one store to another by the "Selector Property" store may exist as physical files in multiple stores, but is referenced with the same content URL
• after migration, content in old store is not considered orphaned as a different node may still reference it (i.e. a copy of the content file with old selector property value) and there is no way to check (URLs are identical, so DB lookup doesn't help and would require a lot of reverse-applying routing logic)
• upon a failed migration between stores, the potentially existing partial content on the target store cannot be cleaned up as content cleaner works on content URL and would end up cleaning the original

Somehow we need to ensure that every distinct store that handles physically stored content produces a unique content URL that differentiates it from other stores. On the other hand we still need to have a semi-transferable identity element to the content URL that allows i.e. checking if the same content exists in a different store (what the "Selector Property" store must do to avoid creating duplicates).

[AFaust]

This module defines an abstract "wildcard" store protocol that any physical store in this module must support. This protocol can be used to define a semi-transferable identity (content URL) to use in checking content existence and pre-defining content URLs of new content items. A physical store must replace the protocol with its concrete value during internal operations and expose a final, concrete content URL for new content items. A client is thus completely isolated from any assumption about a content store and its internal protocol. By configuring custom store protocols for physical stores we can now support proper orphan handling e.g. for routing stores. When a content is actually moved / copied to another physical store with a different protocol, the old content may be orphaned if no other node references the same URL.