This ensures graphical progress is shown ASAP when dependencies are
equally likely to run.
Otherwise, when the graphical step was ready, and switchroot about to
run, the shell step could run before the splash. This means that, in
practice, a long running task like e2fsck could have prevented the
splash to show. It doesn't make sense to make the other tasks depend on
a splash task!
There is no intention to implement any other special-cased ordering. If
there is the need to, it might mean that there is a deficiency in the
design.
This is partly to reduce the amount of loops it needs to run, but mainly
to control the order rather than rely on the order they were added in.
The control of order seems weird in a dependency-based system, but it'll
be used mainly for one thing in the next commit...
