deps reload: 'reload' flag - reload dep file and update graph and plan in build time

Dep file is reloaded and dependencies are reevaluated for edges with
rules specifying 'reload=1'. If dirty dependencies are discovered, the
edge is not marked as 'built', and is scheduled for repeated rebuild
after the discovered dependencies are cleaned.

The indended usage is supporting rules generating dependency files.
The proposed usage pattern is:

>>
build auto.o: CC auto.c | auto.d
    cc_options =

build auto.d: DEP auto.c
    cc_options =

rule DEP
    command = gcc -MM -MG $in -MF $out -MT $out $cc_options
    depfile = $out
    deps = gcc    # (deps mode is optional)
    reload = 1
<<

Since both .o and .d should have the same dependency list (with the
exception of command line dependencies), we make .o depending on
.d, which __specifies its target as a dep file__, and therefore depends
on all files required to build .o (or to update its dependencies list).

Discussion
==========

This approach is somewhat similar to have a 'depcommand' attribute in
rules, running before the command is executed to evaluate dependencies.
Here this command runs on a separate edge. This simplifies implementation
and syntax. For instance, it allows giving depcommand its own
'description' w/o adding yet another rule attribute.

Number of such 'rebuilds' is final and limited by number of
dirty targets in the project, if at each iteration a new dependency is
discovered. In the real scenarios, the number of rebuilds is small and optimal:
Each dependencies discovery iteration finds a next level of nesting
of required autogenerated header files, and rebuild is only needed if
these were not generated yet (could be generated already if these
are required by other targets as well).

This patch is a rewritten version of original the patch for ninja v1.0.
Major changes code changes were required to support deps=gcc type dependencies.