Fixes to "Threading and Tasks in Chrome" documentation.

docs/threading_and_tasks.md

 # Threading and Tasks in Chrome
 
 [TOC]
 
 ## Overview
 
 ### Threads
 
 Every Chrome process has
 
@@ skipping 57 matching lines @@
 The `base::PostTask*WithTraits()` functions allow the caller to provide
 additional details about the task via TaskTraits (ref.
 [Annotating Tasks with TaskTraits](#Annotating-Tasks-with-TaskTraits)).
 
 ```cpp
 base::PostTaskWithTraits(
     FROM_HERE, {base::TaskPriority::BACKGROUND, MayBlock()},
     base::BindOnce(&Task));
 ```
 
-## Posting via a TaskRunner
+### Posting via a TaskRunner
 
 A parallel
 [`TaskRunner`](https://cs.chromium.org/chromium/src/base/task_runner.h) is an
 alternative to calling `base::PostTask*()` directly. This is mainly useful when
 it isn’t known in advance whether tasks will be posted in parallel, in sequence,
-or to a single-thread (ref. [Posting a Sequenced Task](#Posting-a-Sequenced-
-Task), [Posting Multiple Tasks to the Same Thread](#Posting-Multiple-Tasks-to-
-the-Same-Thread)). Since `TaskRunner` is the base class of `SequencedTaskRunner`
-and `SingleThreadTaskRunner`, a `scoped_refptr<TaskRunner>` member can hold a
+or to a single-thread (ref.
+[Posting a Sequenced Task](#Posting-a-Sequenced-Task),
+[Posting Multiple Tasks to the Same Thread](#Posting-Multiple-Tasks-to-the-Same-Thread)).
+Since `TaskRunner` is the base class of `SequencedTaskRunner` and
+`SingleThreadTaskRunner`, a `scoped_refptr<TaskRunner>` member can hold a
 `TaskRunner`, a `SequencedTaskRunner` or a `SingleThreadTaskRunner`.
 
 ```cpp
 class A {
  public:
   A() = default;
 
   void set_task_runner_for_testing(
       scoped_refptr<base::TaskRunner> task_runner) {
     task_runner_ = std::move(task_runner);
@@ skipping 112 matching lines @@
 
 ```cpp
 content::BrowserThread::GetTaskRunnerForThread(content::BrowserThread::UI)
     ->PostTask(FROM_HERE, ...);
 
 content::BrowserThread::GetTaskRunnerForThread(content::BrowserThread::IO)
     ->PostTask(FROM_HERE, ...);
 ```
 
 The main thread and the IO thread are already super busy. Therefore, prefer
-posting to a general purpose thread when possible (ref. [Posting a Parallel
-Task](#Posting-a-Parallel-Task), [Posting a Sequenced task](#Posting-a
--Sequenced-Task)).  Good reasons to post to the main thread are to update the UI
-or access objects that are bound to it (e.g. `Profile`). A good reason to post
-to the IO thread is to access the internals of components that are bound to it
-(e.g. IPCs, network). Note: It is not necessary to have an explicit post task to
-the IO thread to send/receive an IPC or send/receive data on the network.
+posting to a general purpose thread when possible (ref.
+[Posting a Parallel Task](#Posting-a-Parallel-Task),
+[Posting a Sequenced task](#Posting-a-Sequenced-Task)).
+Good reasons to post to the main thread are to update the UI or access objects
+that are bound to it (e.g. `Profile`). A good reason to post to the IO thread is
+to access the internals of components that are bound to it (e.g. IPCs, network).
+Note: It is not necessary to have an explicit post task to the IO thread to
+send/receive an IPC or send/receive data on the network.
 
 ### Posting to the Main Thread in a Renderer Process
 TODO
 
 ### Posting to a Custom SingleThreadTaskRunner
 
 If multiple tasks need to run on the same thread and that thread doesn’t have to
 be the main thread or the IO thread, post them to a `SingleThreadTaskRunner`
 created by `base::CreateSingleThreadTaskRunnerWithTraits`.
 
@@ skipping 368 matching lines @@
 
 ```cpp
 base::TaskScheduler::GetInstance()->Shutdown();
 // Tasks posted with TaskShutdownBehavior::BLOCK_SHUTDOWN and
 // tasks posted with TaskShutdownBehavior::SKIP_ON_SHUTDOWN that
 // have started to run before the Shutdown() call have now completed their
 // execution. Tasks posted with
 // TaskShutdownBehavior::CONTINUE_ON_SHUTDOWN may still be
 // running.
 ```