Optimize dependency links in flattening

With this change a link between two subflows caused by task dependency
does not impose execution ordering between all tasks of that subflows
any more: only provider and consumer of the dependency are now linked.
For some cases this is a major optimization, as it allows more
independent parts of the flow to be executed or reverted in parallel. It
also allows, for example, converting parts of flow into subflows without
loosing performance.

Because with this change parts of parent flow that depend on some tasks
in subflow can be executed before all tasks in the subflow are
completed, graph analyzer is changed to not stop at subflow border when
iterating subgraphs.

Change-Id: I45587a4e851febe3c43cfa7b74bdfc50f61e0279
Use same code to reset flow and parts of it

Instead of having special engine and storage method to reset
reverted flow when running it again, delegate the job to
graph action, which already does almost same thing when retrying
subgraphs.

Change-Id: Icf257cfc0fb161ab2199baa3d7c7e64664a109e7
Merge "Optimize dependency links in flattening"
Merge "Use same code to reset flow and parts of it"