Fix generators to make sure changes to rule inputs trigger correct rebuilds....

Fix generators to make sure changes to rule inputs trigger correct rebuilds.
Currently disabled for MSVS and XCode.
BUG=none
TEST=none

Committed: http://code.google.com/p/gyp/source/detail?r=763

[sgk, 2009-10-20 15:03:45]

Mark, could you take a look at this test configuration?  It's a stripped-down
case to mimic how we generate the .cpp and .h files for webcore bindings.

Xcode isn't doing what I expect.  When the .in file changes, it re-runs the rule
correctly (re-generates the .cpp and .h) but then doesn't actually recompile the
changed .cpp.

(Make and SCons handle it, although I needed the one-line make.py fix in this
CL.  Visual Studio has a problem in the generated makefile when
msvs_external_rule=1 is used, which is the original impetus for this CL.)

[Mark Mentovai, 2009-10-20 15:58:13]

LGTM.

TVL and I know that there's an Xcode bug here.  I think it's timing-sensitive:
if the rules take long enough to run, Xcode will notice that there are touched
.c and .h files, and compile.

I think we're going to need to break rules and actions into auxiliary targets to
enforce proper ordering in Xcode.

[sgk, 2009-11-23 23:21:21]

Didn't land this earlier because MSVS still has problems with it, too.  (Partly
the generator, partly test execution when cygwin has to be involved to run
make.)  I opened issue 120 to track that separately from the Xcode problem, and
will land it with MSVS execution disabled.