This solved a problem with non-deterministic output from opt due
to not performing dominator tree updates in a deterministic order.
The problem found was the JumpThreading used the DomTreeUpdater via
llvm::MergeBasicBlockIntoOnlyPred. And when preparing the list of
updates to send to DomTreeUpdater::applyUpdates we iterated over
a SmallPtrSet, which does not give a well-defined order.
The added domtree-updates.ll test case is an example that would
result in non-deterministic printouts of the domtree. Semantically
those domtree:s where equivalent, but since passes (at least EarlyCSE)
are iterating over nodes in the dominator tree the order in which
transforms are applied transitively also depend on the order in which
dominator tree updates are performed.
unordered -> ordered also here?