Tweaks to cc docs

The first paragraph of a doc page is rendered
as some sort of synopsis/subtitle, which looked
awkward with the current text. This change adds
introduction headings, which also improves the
navigation on the right-hand side of a page.

Author: bracevac

docs/_docs/reference/experimental/capture-checking/cc.md

@@ -4,7 +4,11 @@ title: "Capture Checking"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/cc.html
 ---
 
-Capture checking is a research project that modifies the Scala type system to track references to capabilities in values. It can be enabled by the language import
+Capture checking is a research project that modifies the Scala type system to track references to capabilities in values.
+
+## Introduction
+
+Capture checking can be enabled by the language import
 ```scala
 import language.experimental.captureChecking
 ```

docs/_docs/reference/experimental/capture-checking/checked-exceptions.md

@@ -4,6 +4,8 @@ title: "Checked Exceptions"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/checked-exceptions.html
 ---
 
+## Introduction
+
 Scala enables checked exceptions through a language import. Here is an example,
 taken from the [safer exceptions page](../canthrow.md), and also described in a
 [paper](https://infoscience.epfl.ch/record/290885) presented at the

docs/_docs/reference/experimental/capture-checking/classes.md

@@ -4,6 +4,7 @@ title: "Capture Checking of Classes"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/classes.html
 ---
 
+## Introduction
 
 The principles for capture checking closures also apply to classes. For instance, consider:
 ```scala

docs/_docs/reference/experimental/capture-checking/classifiers.md

@@ -4,6 +4,8 @@ title: "Capability Classifiers"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/classifiers.html
 ---
 
+## Introduction
+
 Capabilities are extremely versatile. They can express concepts from many different domains. Exceptions, continuations, I/O, mutation, information flow, security permissions, are just some examples, the list goes on.
 
 Sometimes it is important to restrict, or: _classify_ what kind of capabilities are expected or returned in a context. For instance, we might want to allow only control capabilities such as `CanThrow`s or boundary `Label`s but no

docs/_docs/reference/experimental/capture-checking/polymorphism.md

@@ -4,6 +4,8 @@ title: "Capability Polymorphism"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/polymorphism.html
 ---
 
+## Introduction
+
 It is sometimes convenient to write operations that are parameterized with a capture set of capabilities. For instance consider a type of event sources
 `Source` on which `Listener`s can be registered. Listeners can hold certain capabilities, which show up as a parameter to `Source`:
 ```scala

docs/_docs/reference/experimental/capture-checking/scoped-caps.md

@@ -4,6 +4,8 @@ title: "Scoped Caps"
 nightlyOf: https://docs.scala-lang.org/scala3/reference/experimental/capture-checking/scoped-caps.html
 ---
 
+## Introduction
+
 When discussing escape checking, we referred to a scoping discipline. That is, capture sets can contain only capabilities that are visible at the point where the set is defined. But that raises the question where a universal capability `cap` is defined? In fact, what is written as the top type `cap` can mean different capabilities, depending on scope. Usually a `cap` refers to a universal capability defined in the scope where the `cap` appears.
 
 Special rules apply to `cap`s in method and function parameters and results. For example, take this method: