Non-deterministic execution order of overlapping delta-merge initializeitems with the same sequence

The repository bootstrap InitializationProcessorImpl, since 11.0+, sorts InitializeItems to be executed based on more than just their sequence and name: also their relative dependency as possible 'downstream item' is taken into account.
The current check to determine if one initializeitem is a downstream depedency of another still can go wrong because it doesn't takes multiple overlapping contentresource initializeitems into account.
This can go wrong when two or more contentresource initializeitems with the same sequence number are all using the same (first) "hippo:contextpaths" (multi-valued derived property on an initialize item).
It is possible to have multiple of such items when one or more of those are of type delta-merge (derived property "hipposys:deltadirective"), even in combination with a (single) non-delta-merge (e.g. 'standard') initializeitem.
Such initializeitems are all downstream of each other, which makes the (binary search based) sorting non-deterministic, depending on the relatively random order of these items before/during the sorting.

This could have gone wrong and be noticed already since May 2015, but it didn't, at least not consistent enough for us to notice.
And it can come and go again at anytime, because of the unpredictable loading order of the hippoecm-extension.xml resources, as well as the order of the initializeitems therein.

This needs to be fixed properly in the repository bootstrap inititialization processor logic itself, so requires a product fix to be backported to 11.0.