input.py should propagate hard_dependency as part of export_dependent_settings dependency propagation

[GoogleCodeExporter]

static_library targets must specify hard_dependency when they produce e.g. 
headers that are needed by libraries that depend on them. This is common for 
instance when a library generates headers from a protocol buffer. See 
http://code.google.com/p/gyp/wiki/InputFormatReference#Linking_Dependencies

If a library declares itself as a hard_dependency, and another library that 
depends on that library includes the hard_dependency library in its 
export_dependent_settings (e.g. because it includes a header from the 
hard_dependency library in its public interface) then the hard_dependency 
relationship needs to be propagated forward to all of the libraries that 
indirectly depend on the hard_dependency library due to 
export_dependent_settings.

Original issue reported on code.google.com by bmcqu...@google.com on 4 Feb 2012 at 6:12

[GoogleCodeExporter]

imagine for instance I have library A that generates headers and puts them 
somewhere under shared_intermediate_dir. library A adds an include_dirs entry 
for that shared_intermediate_dir to its direct_dependent_settings. library A 
also sets hard_dependency bit.

I then have library B that includes a generated header from library A in its 
public interface. it thus puts library A in its export_dependent_settigns.

Finally I have library C that includes the public interface of library B and 
declares a dependency on library B.

Currently library C will attempt to build before library A, which causes a 
build failure.

My workaround is to declare a dependency from library C to library A, but 
ideally this would be taken care of by gyp.

Original comment by bmcqu...@google.com on 4 Feb 2012 at 6:20