Update and fix some markdown docs

docs/chromium_integration.md

 ## Design documents
 
 *   [Chromium integration for Win32, Linux and Mac]
     (http://docs.google.com/View?id=dhhbw89r_0c7w4rxdc)
 *   [Chromium integration for Win64]
     (http://docs.google.com/View?id=dhhbw89r_2p9wgf5tg)
 
 ## Build system
 
 Most of NaCl, including the trusted runtime and tests, is built using Scons.
-However, Chromium ignores NaCl's Scons build system and uses Gyp to build NaCl
+However, Chromium ignores NaCl's Scons build system and uses gn to build NaCl
 (in the same way as it ignores Webkit's own build system). This is why there are
-`*.gyp` and `*.gypi` files in the NaCl tree, though the NaCl standalone build
+`*.gn` and `*.gni` files in the NaCl tree, though the NaCl standalone build
 doesn't use them. These Gyp files cover NaCl's trusted code but not tests.
 
 ## sel\_ldr
 
 On some systems, the code that is normally in sel\_ldr is statically linked into
 the Chromium executable. (The Gyp build also has a target to build a standalone

[bradnelson, 2016/10/28 14:43:28]

Change this too?

 sel\_ldr, but this is mainly for testing purposes.)
 
 Linking sel\_ldr into Chromium has some advantages: * It reduces version skew
 issues. * It makes it easier to run sel\_ldr inside the sandbox. On Linux,
 sel\_ldr can be launched by forking Chromium's Zygote process, which is already
 set up to be sandboxed. This can also reduce per-instance startup costs a
 little. * It makes it easier for sel\_ldr to link to Chromium-specific code
 (e.g. code specific to the Chromium Linux sandbox).
 
 However, there also some good reasons to build sel\_ldr as a separate
@@ skipping 31 matching lines @@
 ## Policy on dependencies
 
 Native Client should not #include files from the "chrome" directory in the
 Chromium source tree. However, #including files from other directories (such as
 "base") might be OK. For some background, see [issue 469]
 (http://code.google.com/p/nativeclient/issues/detail?id=469).
 
 ## See also
 
 *   GypBuild