[mlir] add TOC to top-level documents

Multiple top-level MLIR documents did not have a table of contents tag,
making them harder to nagivate.

mlir/docs/BufferDeallocationInternals.md

@@ -5,6 +5,8 @@ transformation. The transformation consists of several passes. The main pass
 called BufferDeallocation can be applied via “-buffer-deallocation” on MLIR
 programs.
 
+[TOC]
+
 ## Requirements
 
 In order to use BufferDeallocation on an arbitrary dialect, several control-flow

mlir/docs/CAPI.md

@@ -2,6 +2,8 @@
 
 **Current status: Under development, API unstable, built by default.**
 
+[TOC]
+
 ## Design
 
 Many languages can interoperate with C but have a harder time with C++ due to

mlir/docs/Canonicalization.md

@@ -15,6 +15,8 @@ reuse it across many different IRs that it represents. This document describes
 the general approach, global canonicalizations performed, and provides sections
 to capture IR-specific rules for reference.
 
+[TOC]
+
 ## General Design
 
 MLIR has a single canonicalization pass, which iteratively applies

mlir/docs/DataLayout.md

@@ -21,6 +21,8 @@ Built-in types are handled specially to decrease the overall query cost.
 Similarly, built-in `ModuleOp` supports data layouts without going through the
 interface.
 
+[TOC]
+
 ## Usage
 
 ### Scoping

mlir/docs/DebugActions.md

@@ -1,7 +1,5 @@
 # Debug Actions
 
-[TOC]
-
 This file documents the infrastructure for `Debug Actions`. This is a DEBUG only
 API that allows for external entities to control various aspects of compiler
 execution. This is conceptually similar to something like `DebugCounters` in
@@ -23,6 +21,8 @@ The exact definition of an `external entity` is left opaque, to allow for more
 interesting handlers. The set of possible action queries is detailed in the
 [`action manager`](#debug-action-manager) section below.
 
+[TOC]
+
 ## Debug Action
 
 A `debug action` is essentially a marker for a type of action that may be

mlir/docs/DeclarativeRewrites.md

@@ -17,6 +17,8 @@ for the latter.
 Given that declarative rewrite rules depend on op definition specification, this
 manual assumes knowledge of the [ODS](OpDefinitions.md) doc.
 
+[TOC]
+
 ## Benefits
 
 Compared to the hand-written C++ classes, this declarative approach has several

mlir/docs/DialectConversion.md

@@ -5,14 +5,14 @@ conversions between, and within dialects. This framework allows for transforming
 illegal operations to those supported by a provided conversion target, via a set
 of pattern-based operation rewriting patterns.
 
-[TOC]
-
 The dialect conversion framework consists of the following components:
 
 *   A [Conversion Target](#conversion-target)
 *   A set of [Rewrite Patterns](#rewrite-pattern-specification)
 *   A [Type Converter](#type-conversion) (Optional)
 
+[TOC]
+
 ## Modes of Conversion
 
 When applying a conversion to a set of operations, there are several different

mlir/docs/Interfaces.md

@@ -8,6 +8,8 @@ to account for the semantics of every operation, or be overly conservative.
 Without care, this can result in code with special-cases for each supported
 operation type. To combat this, MLIR provides a concept of `interfaces`.
 
+[TOC]
+
 ## Motivation
 
 Interfaces provide a generic way of interacting with the IR. The goal is to be

mlir/docs/OpDefinitions.md

@@ -16,6 +16,8 @@ for the latter.
 In addition to detailing each mechanism, this manual also tries to capture best
 practices. They are rendered as quoted bullet points.
 
+[TOC]
+
 ## Motivation
 
 MLIR allows pluggable dialects, and dialects contain, among others, a list of

mlir/docs/ShapeInference.md

@@ -17,6 +17,8 @@ inference. The return type can often be deduced from the deduced return shape
 and elemental type (queryable from `InferShapedTypeOpInterface`) and so type
 inference for tensor types can be implemented with `InferShapedTypeOpInterface`.
 
+[TOC]
+
 ## Shape functions
 
 The C++ interfaces are the base mechanism whereby shape inference is queried and