Check system-include dependencies in GN

Check system-include dependencies in GN

"gn check" previously only checked header include lines that used
quotes. With this commit all include lines are checked and
it still reports OK for the whole chromium repo.
This makes GN easier to integrate with external projects and makes
the dependency check more robust.

R=brettw@chromium.org, dpranke@chromium.org
BUG=

[Dirk Pranke, 2016-01-26 22:21:02]

why doesn't including <stdio.h> or, perhaps better, something like <sys/errno.h>
cause gn check to fail?

[NGG, 2016-01-27 00:00:31]

On 2016/01/26 22:21:02, Dirk Pranke wrote:
> why doesn't including <stdio.h> or, perhaps better, something like
<sys/errno.h>
> cause gn check to fail?

AFAIK GN only checks the include files that are listed in the sources of a
target. It says OK if all these included targets are proper dependencies. It
simply ignores the include lines for which it cannot find a target. 

It doesn't even fail for #include "stdio.h"

I think this logic should be improved a bit,  for example if an action has a
header file output and that is included from another target then it doesn't
check the dependency between these. I think it doesn't even check include paths,
it only recognizes relative paths from the root directory. I think tbis should
be addressed as well later.

[Dirk Pranke, 2016-01-27 00:37:11]

Okay, the change lgtm , then if it is the intended behavior.

Brett, can you confirm / review this as well?

[NGG, 2016-01-27 01:30:56]

On 2016/01/27 00:00:31, NGG wrote:
> I think this logic should be improved a bit,  for example if an action has a
> header file output and that is included from another target then it doesn't
> check the dependency between these. I think it doesn't even check include
paths,
> it only recognizes relative paths from the root directory. I think tbis should
> be addressed as well later.

I was actually wrong about it, it checks include files that are either sources,
public_headers or outputs of a target. It only matches the include line to a
file in a target if the include is a relative path from the root directory,
or if it is a relative path from root_gen_dir.

I thought it doesn't work for actions, because I tried to use it in a wrong way.
The action I tried it didn't generate the file to root_gen_dir but to
target_gen_dir
and that directory was added as an include path, that's why it didn't find it.
If the target's output is in root_gen_dir then it works as expected.

[brettw, 2016-02-01 23:53:50]

What ideally would happen is that GN would take into account its understanding
of the include path to be able to resolve all includes. That way we would be
able to handle Chrome-style absolute paths, and other styles used by other
projects, including some third-party projects in Chrome where we have to hack
things a bit.

As-is though, this change will see <stdio.h> and convert it to the GN path
"//stdio.h" and see if it matches any file in the project. If GN doesn't match
any file in the project, it ignores the include. This is pretty confusing
because //stdio.h is definitely not what you meant when you included stdio, and
checking these doesn't add any benefit.

The only thing that this helps are projects that include things by full path
relative to the source, but use <> instead of "" for such includes. This
actually seems pretty rare to me. We have a few instances of screwups in Chrome
where people used <> instead of "", but these were rare and I suspect some of
them were actually to disable the header checker.

Today GN checks headers according to Chrome's include style. This works well but
is incomplete. If we're not happy with this, I think we should do the right
solution I described above rather than trying to hack the current solution.