gyp: use all processors instead of hard-coded 8.

Makes no difference for me but might help others because gyp can easily
keep lots of processors busy.

BUG=362075

Originally landed at r1896 and backed out at r1911. This should be safe
to land after r1913.

Patch by Daniel Bratell <bratell@opera.com>.

R=torne@chromium.org

Review URL: https://codereview.chromium.org/267023005

git-svn-id: http://gyp.googlecode.com/svn/trunk@1928 78cadc50-ecff-11dd-a971-7dbc132099af
Fix msvs-ninja clean build command / target.

Currently the clean command is specified as

ninja.exe -C $(OutDir) -t clean $(ProjectName)

but _BuildCommandLineForRuleRaw sees 'clean' as a path, calling _FixPath on it.
This is not a problem for Chromium because it does not set --generator-output.
As a result fixpath_prefix is None and no adjustment is made to paths.
Skia, however, does set --generator-output, and so an attempt is made to adjust
paths with _FixPath. As a result, with Skia the msvs 'Clean' target contains

ninja.exe -C $(OutDir) -t ../../gyp/clean $(ProjectName)

This change changes the command to

ninja.exe -C $(OutDir) -tclean $(ProjectName)

which it valid for ninja, but _BuildCommandLineForRuleRaw will not _FixPath it.

BUG=skia:2439
R=sbaig1@bloomberg.net

Review URL: https://codereview.chromium.org/314163003

git-svn-id: http://gyp.googlecode.com/svn/trunk@1929 78cadc50-ecff-11dd-a971-7dbc132099af
Add option for link concurrency.

Skia's buildbots, particularly Windows builds with LTO, are held back by the
link pool.  We'd like to play around with this number a bit.  Any problem
checking an environment variable first before doing the RAM-based calculation?

Testing: ran with and without GYP_LINK_CONCURRENCY=90, looked at build.ninja

Patch from mtklein@chromium.org.

R=scottmg@chromium.org

Review URL: https://codereview.chromium.org/315343003

git-svn-id: http://gyp.googlecode.com/svn/trunk@1930 78cadc50-ecff-11dd-a971-7dbc132099af