GN threading refactor

Refactor the GN threading model to reduce locking and simplify execution.

Old design: item_tree manages dependency resolution, target_manager creates and hooks up the target dependencies, and the toolchain manager does all kinds of crazy ordering and loading stuff on every thread. There is lots of locking every time the dependency tree is modified.

This patch completely deletes the toolchain manager, item tree, item node, and target manager.

The new design is that the build files are executed on background threads, but then they come back to the main thread which assembles the dependency tree and schedules other file loads. This eliminates almost all locking and a lot of complexity.

The Loader now manages loading the different build files in the correct context, and managing dependencies (loading the build config first, for example). The Builder manages the dependency tree and requests that the Loader load files that it encounters references to.

This simpler design reduces non-test code by ~350 lines. In the current gn build, lock acquisitions go down from 1808 to 116 and it saves about 20ms wall clock time (8% faster). This is a bit deceiving, though, because most of the time is spent on pkg-config which is constant. It speeds up running individual build files by 1000-1500%.

The work of putting the tree together that used to take up this time inside locks is now transferred to the main thread, which looks like it is *sometimes* a bottleneck. This should be easier to optimize in the future, though.

Other tweaks:
 - I fixed cycle finding
 - Directories look prettier on Windows using the "desc" command
 - Tracing output now includes the main thread and marks it as such
 - I updated the base BUILD.gn file for the more recent tree.

R=scottmg@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=234032

[scottmg, 2013-11-08 05:06:21]

Seems a lot better.

lgtm

[brettw, 2013-11-08 23:25:50]

Committed patchset #18 manually as r234032 (presubmit successful).