Move sub-pages of "Layout Tests" from Google Sites to Markdown.

docs/testing/layout_tests.md

 # Layout Tests
 
 Layout tests are used by Blink to test many components, including but not
 limited to layout and rendering. In general, layout tests involve loading pages
 in a test renderer (`content_shell`) and comparing the rendered output or
 JavaScript output against an expected output file.
 
 [TOC]
 
 ## Running Layout Tests
@@ skipping 162 matching lines @@
 than a certain amount of time to complete is aborted and marked as "timed out".
 A row of dots in the script's output indicates one or more tests that passed.
 
 ## Test expectations
 
 The
 [TestExpectations](../../WebKit/LayoutTests/TestExpectations) file (and related
 files, including
 [skia_test_expectations.txt](../../skia/skia_test_expectations.txt))
 contains the list of all known layout test failures. See
-[Test Expectations](https://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/testexpectations)
+[Test Expectations](./layout_test_expectations.md)
 for more on this.
 
 ## Testing Runtime Flags
 
 There are two ways to run layout tests with additional command-line arguments:
 
 * Using `--additional-driver-flag`:
 
   ```bash
   run-webkit-tests --additional-driver-flag=--blocking-repaint
@@ skipping 219 matching lines @@
     * If your test contains a JS call, DOM manipulation, or other distinctive
       piece of code that you think is failing, search for that in the Chrome
       solution. That's a good place to put a starting breakpoint to start
       tracking down the issue.
     * Otherwise, you're running in a standard message loop just like in Chrome.
       If you have no other information, set a breakpoint on page load.
 * If your test only works in full layout-test mode, or if you find it simpler to
   debug without all the overhead of an interactive session, start the
   content_shell with the command-line flag `--run-layout-test`, followed by the
   URL (file: or http:) to your test. More information about running layout tests
-  in content_shell can be found
-  [here](https://www.chromium.org/developers/testing/webkit-layout-tests/content-shell).
+  in content_shell can be found [here](./layout_tests_in_content_shell.md).
     * In VS, you can do this in the Debugging section of the content_shell
       project Properties.
     * Now you're running with exactly the same API, theme, and other setup that
       the layout tests use.
     * Again, if your test contains a JS call, DOM manipulation, or other
       distinctive piece of code that you think is failing, search for that in
       the Chrome solution. That's a good place to put a starting breakpoint to
       start tracking down the issue.
     * If you can't find any better place to set a breakpoint, start at the
       `TestShell::RunFileTest()` call in `content_shell_main.cc`, or at
@@ skipping 71 matching lines @@
 * Open `http://localhost:9222` in a stable/beta/canary Chrome, click the single
   link to open the devtools with the test loaded.
 * You may need to replace devtools.html with inspector.html in your URL (or you
   can use local chrome inspection of content_shell from chrome://inspect
   instead)
 * In the loaded devtools, set any required breakpoints and execute `test()` in
   the console to actually start the test.
 
 ## Rebaselining Layout Tests
 
-_To automatically re-baseline tests across all Chromium platforms, using the
+*** promo
+To automatically re-baseline tests across all Chromium platforms, using the
 buildbot results, see the
-[Rebaselining keywords in TestExpectations](https://www.chromium.org/developers/testing/webkit-layout-tests/testexpectations#TOC-Rebaselining)
-and
+[Rebaselining keywords in TestExpectations](./layout_test_expectations.md)
+and the
 [Rebaselining Tool](https://trac.webkit.org/wiki/Rebaseline).
 Alternatively, to manually run and test and rebaseline it on your workstation,
-read on._
+read on.
+***
 
 By default, text-only tests (ones that call `testRunner.dumpAsText()`) produce
 only text results. Other tests produce both new text results and new image
 results (the image baseline comprises two files, `-expected.png` and
   `-expected.checksum`). So you'll need either one or three `-expected.\*` files
 in your new baseline, depending on whether you have a text-only test or not. If
 you enable `--no-pixel-tests`, only new text results will be produced, even for
 tests that do image comparisons.
 
 ```bash
@@ skipping 22 matching lines @@
 See
 [bugs with the component Blink>Infra](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3ABlink%3EInfra)
 for issues related to Blink tools, include the layout test runner.
 
 * Windows and Linux: Do not copy and paste while the layout tests are running,
   as it may interfere with the editing/pasteboard and other clipboard-related
   tests. (Mac tests swizzle NSClipboard to avoid any conflicts).
 * If QuickTime is not installed, the plugin tests
   `fast/dom/object-embed-plugin-scripting.html` and
   `plugins/embed-attributes-setting.html` are expected to fail.