Fix some dead links in docs/testing

1. Change breakpad path to third_party/breakpad
- docs/testing/using_breakpad_with_content_shell.md
moved in https://chromium-review.googlesource.com/681838

2. Change componetns/test_runner to content/shell_test_runner
- docs/testing/writing_layout_tests.md
moved in https://codereview.chromium.org/2707183003

3. Fix testharness api link
- docs/testing/layout_tests_tips.md
https://github.com/w3c/testharness.js is moved under
https://github.com/w3c/web-platform-tests

Bug: N/A
Change-Id: I3c1024da6bc3ae9a785cb597e3b76dbd910b2593
Reviewed-on: https://chromium-review.googlesource.com/1049767Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557098}

docs/testing/layout_tests_tips.md

@@ -107,7 +107,7 @@ valid markup (no parsing errors).
 
 Tests should provide as much relevant information as possible when failing.
 `testharness.js` tests should prefer
-[rich assert_ functions](https://github.com/w3c/testharness.js/blob/master/docs/api.md#list-of-assertions)
+[rich assert_ functions](https://github.com/w3c/web-platform-tests/blob/master/docs/_writing-tests/testharness-api.md#list-of-assertions)
 to combining `assert_true()` with a boolean operator. Using appropriate
 `assert_` functions results in better diagnostic output when the assertion
 fails.

docs/testing/using_breakpad_with_content_shell.md

 # Using breakpad with content shell
 
 When running layout tests, it is possible to use
-[breakpad](../../breakpad/) to capture stack traces on crashes while
+[breakpad](../../third_party/breakpad/) to capture stack traces on crashes while
 running without a debugger attached and with the sandbox enabled.
 
 ## Setup

docs/testing/writing_layout_tests.md

@@ -224,9 +224,9 @@ other tests that use it, or reading its source code.
 
 For example, the most popular Blink-specific API is `testRunner`, which is
 implemented in
-[components/test_runner/test_runner.h](../../components/test_runner/test_runner.h)
+[content/shell/test_runner/test_runner.h](../../content/shell/test_runner/test_runner.h)
 and
-[components/test_runner/test_runner.cc](../../components/test_runner/test_runner.cc).
+[content/shell/test_runner/test_runner.cc](../../content/shell/test_runner/test_runner.cc).
 By skimming the `TestRunnerBindings::Install` method, we learn that the
 testRunner API is presented by the `window.testRunner` and
 `window.layoutTestsController` objects, which are synonyms. Reading the
@@ -248,12 +248,12 @@ by tests that stick to Web Platform APIs. The `testharnessreport.js` file in
 and uses the `testRunner` API.
 ***
 
-See the [components/test_runner/](../../components/test_runner/) directory and
+See the [content/shell/test_runner/](../../content/shell/test_runner/) directory and
 [WebKit's LayoutTests guide](https://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree)
 for other useful APIs. For example, `window.eventSender`
-([components/test_runner/event_sender.h](../../components/test_runner/event_sender.h)
+([content/shell/test_runner/event_sender.h](../../content/shell/test_runner/event_sender.h)
 and
-[components/test_runner/event_sender.cc](../../components/test_runner/event_sender.cc))
+[content/shell/test_runner/event_sender.cc](../../content/shell/test_runner/event_sender.cc))
 has methods that simulate events input such as keyboard / mouse input and
 drag-and-drop.