Fix some links in documentation related to layout tests.

docs/testing/writing_layout_tests.md

 # Writing Layout Tests
 
 _Layout tests_ is a bit of a misnomer. This term is
 [a part of our WebKit heritage](https://webkit.org/blog/1452/layout-tests-theory/),
 and we use it to refer to every test that is written as a Web page (HTML, SVG,
 or XHTML) and lives in
 [third_party/WebKit/LayoutTests/](../../third_party/WebKit/LayoutTests).
 
 [TOC]
 
@@ skipping 209 matching lines @@
 a last resort.
 
 A downside of Blink-specific APIs is that they are not as well documented as the
 Web Platform features. Learning to use a Blink-specific feature requires finding
 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)
 and
-[components/test_runner/test_runner.cpp](../../components/test_runner/test_runner.cpp).
+[components/test_runner/test_runner.cc](../../components/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
 `TestRunnerBindings::GetObjectTemplateBuilder` method tells us what properties
 are available on the `window.testRunner` object.
 
 *** aside
 `window.testRunner` is the preferred way to access the `testRunner` APIs.
 `window.layoutTestsController` is still supported because it is used by
 3rd-party tests.
 ***
 
 *** note
 `testRunner` is the most popular testing API because it is also used indirectly
 by tests that stick to Web Platform APIs. The `testharnessreport.js` file in
 `testharness.js` is specifically designated to hold glue code that connects
 `testharness.js` to the testing environment. Our implementation is in
 [third_party/WebKit/LayoutTests/resources/testharnessreport.js](../../third_party/WebKit/LayoutTests/resources/testharnessreport.js),
 and uses the `testRunner` API.
 ***
 
 See the [components/test_runner/](../../components/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)
 and
-[components/test_runner/event_sender.cpp](../../components/test_runner/event_sender.cpp))
+[components/test_runner/event_sender.cc](../../components/test_runner/event_sender.cc))
 has methods that simulate events input such as keyboard / mouse input and
 drag-and-drop.
 
 Here is a UML diagram of how the `testRunner` bindings fit into Chromium.
 
 [![UML of testRunner bindings configuring platform implementation](https://docs.google.com/drawings/u/1/d/1KNRNjlxK0Q3Tp8rKxuuM5mpWf4OJQZmvm9_kpwu_Wwg/export/svg?id=1KNRNjlxK0Q3Tp8rKxuuM5mpWf4OJQZmvm9_kpwu_Wwg&pageid=p)](https://docs.google.com/drawings/d/1KNRNjlxK0Q3Tp8rKxuuM5mpWf4OJQZmvm9_kpwu_Wwg/edit)
 
 ### Text Test Baselines
 
 By default, all the test cases in a file that uses `testharness.js` are expected
@@ skipping 307 matching lines @@
 * The `http/` directory hosts tests that require an HTTP server (see above).
 * The `resources/` subdirectory in every directory contains binary files, such
   as media files, and code that is shared by multiple test files.
 
 *** note
 Some layout tests consist of a minimal HTML page that references a JavaScript
 file in `resources/`. Please do not use this pattern for new tests, as it goes
 against the minimality principle. JavaScript and CSS files should only live in
 `resources/` if they are shared by at least two test files.
 ***