nixos/manual: remove .title fenced divs

pandoc drops .title classes when rendering to docbook, so these are
effectively just paragraphs anyway. without support for including them
in a table of contents the complexity of parsing them in
nixos-render-docs won't be warranted.

doc/hooks/breakpoint.section.md

@@ -10,9 +10,7 @@ nativeBuildInputs = [ breakpointHook ];
 When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
 
 ::: {.note}
-::: {.title}
 Caution with remote builds
-:::
 
 This won’t work with remote builds as the build environment is on a different machine and can’t be accessed by `cntr`. Remote builds can be turned off by setting `--option builders ''` for `nix-build` or `--builders ''` for `nix build`.
 :::

nixos/doc/manual/development/freeform-modules.section.md

@@ -13,9 +13,8 @@ checking for entire option trees, it is only recommended for use in
 submodules.
 
 ::: {#ex-freeform-module .example}
-::: {.title}
 **Example: Freeform submodule**
-:::
+
 The following shows a submodule assigning a freeform type that allows
 arbitrary attributes with `str` values below `settings`, but also
 declares an option for the `settings.port` attribute to have it

nixos/doc/manual/development/option-declarations.section.md

@@ -189,9 +189,7 @@ changing the main service module file and the type system automatically
 enforces that there can only be a single display manager enabled.
 
 ::: {#ex-option-declaration-eot-service .example}
-::: {.title}
 **Example: Extensible type placeholder in the service module**
-:::
 ```nix
 services.xserver.displayManager.enable = mkOption {
   description = "Display manager to use";
@@ -201,9 +199,7 @@ services.xserver.displayManager.enable = mkOption {
 :::
 
 ::: {#ex-option-declaration-eot-backend-gdm .example}
-::: {.title}
 **Example: Extending `services.xserver.displayManager.enable` in the `gdm` module**
-:::
 ```nix
 services.xserver.displayManager.enable = mkOption {
   type = with types; nullOr (enum [ "gdm" ]);
@@ -212,9 +208,7 @@ services.xserver.displayManager.enable = mkOption {
 :::
 
 ::: {#ex-option-declaration-eot-backend-sddm .example}
-::: {.title}
 **Example: Extending `services.xserver.displayManager.enable` in the `sddm` module**
-:::
 ```nix
 services.xserver.displayManager.enable = mkOption {
   type = with types; nullOr (enum [ "sddm" ]);

nixos/doc/manual/development/option-types.section.md

@@ -36,9 +36,8 @@ merging is handled.
     together. This type is recommended when the option type is unknown.
 
     ::: {#ex-types-anything .example}
-    ::: {.title}
     **Example: `types.anything` Example**
-    :::
+
     Two definitions of this type like
 
     ```nix
@@ -357,9 +356,7 @@ you will still need to provide a default value (e.g. an empty attribute set)
 if you want to allow users to leave it undefined.
 
 ::: {#ex-submodule-direct .example}
-::: {.title}
 **Example: Directly defined submodule**
-:::
 ```nix
 options.mod = mkOption {
   description = "submodule example";
@@ -378,9 +375,7 @@ options.mod = mkOption {
 :::
 
 ::: {#ex-submodule-reference .example}
-::: {.title}
 **Example: Submodule defined as a reference**
-:::
 ```nix
 let
   modOptions = {
@@ -408,9 +403,7 @@ multiple definitions of the submodule option set
 ([Example: Definition of a list of submodules](#ex-submodule-listof-definition)).
 
 ::: {#ex-submodule-listof-declaration .example}
-::: {.title}
 **Example: Declaration of a list of submodules**
-:::
 ```nix
 options.mod = mkOption {
   description = "submodule example";
@@ -429,9 +422,7 @@ options.mod = mkOption {
 :::
 
 ::: {#ex-submodule-listof-definition .example}
-::: {.title}
 **Example: Definition of a list of submodules**
-:::
 ```nix
 config.mod = [
   { foo = 1; bar = "one"; }
@@ -446,9 +437,7 @@ multiple named definitions of the submodule option set
 ([Example: Definition of attribute sets of submodules](#ex-submodule-attrsof-definition)).
 
 ::: {#ex-submodule-attrsof-declaration .example}
-::: {.title}
 **Example: Declaration of attribute sets of submodules**
-:::
 ```nix
 options.mod = mkOption {
   description = "submodule example";
@@ -467,9 +456,7 @@ options.mod = mkOption {
 :::
 
 ::: {#ex-submodule-attrsof-definition .example}
-::: {.title}
 **Example: Definition of attribute sets of submodules**
-:::
 ```nix
 config.mod.one = { foo = 1; bar = "one"; };
 config.mod.two = { foo = 2; bar = "two"; };
@@ -489,9 +476,8 @@ Types are mainly characterized by their `check` and `merge` functions.
     ([Example: Overriding a type check](#ex-extending-type-check-2)).
 
     ::: {#ex-extending-type-check-1 .example}
-    ::: {.title}
     **Example: Adding a type check**
-    :::
+
     ```nix
     byte = mkOption {
       description = "An integer between 0 and 255.";
@@ -501,9 +487,8 @@ Types are mainly characterized by their `check` and `merge` functions.
     :::
 
     ::: {#ex-extending-type-check-2 .example}
-    ::: {.title}
     **Example: Overriding a type check**
-    :::
+
     ```nix
     nixThings = mkOption {
       description = "words that start with 'nix'";

nixos/doc/manual/development/settings-options.section.md

@@ -144,9 +144,8 @@ These functions all return an attribute set with these values:
     :::
 
 ::: {#ex-settings-nix-representable .example}
-::: {.title}
 **Example: Module with conventional `settings` option**
-:::
+
 The following shows a module for an example program that uses a JSON
 configuration file. It demonstrates how above values can be used, along
 with some other related best practices. See the comments for
@@ -220,9 +219,7 @@ the port, which will enforce it to be a valid integer and make it show
 up in the manual.
 
 ::: {#ex-settings-typed-attrs .example}
-::: {.title}
 **Example: Declaring a type-checked `settings` attribute**
-:::
 ```nix
 settings = lib.mkOption {
   type = lib.types.submodule {

nixos/doc/manual/development/writing-modules.chapter.md

@@ -37,9 +37,7 @@ options, but does not declare any. The structure of full NixOS modules
 is shown in [Example: Structure of NixOS Modules](#ex-module-syntax).
 
 ::: {#ex-module-syntax .example}
-::: {.title}
 **Example: Structure of NixOS Modules**
-:::
 ```nix
 { config, pkgs, ... }:
 
@@ -102,9 +100,7 @@ Exec directives](#exec-escaping-example) for an example. When using these
 functions system environment substitution should *not* be disabled explicitly.
 
 ::: {#locate-example .example}
-::: {.title}
 **Example: NixOS Module for the "locate" Service**
-:::
 ```nix
 { config, lib, pkgs, ... }:
 
@@ -165,9 +161,7 @@ in {
 :::
 
 ::: {#exec-escaping-example .example}
-::: {.title}
 **Example: Escaping in Exec directives**
-:::
 ```nix
 { config, lib, pkgs, utils, ... }:
 

nixos/doc/manual/installation/installing.chapter.md

@@ -538,9 +538,7 @@ drive (here `/dev/sda`). [Example: NixOS Configuration](#ex-config) shows a
 corresponding configuration Nix expression.
 
 ::: {#ex-partition-scheme-MBR .example}
-::: {.title}
 **Example: Example partition schemes for NixOS on `/dev/sda` (MBR)**
-:::
 ```ShellSession
 # parted /dev/sda -- mklabel msdos
 # parted /dev/sda -- mkpart primary 1MB -8GB
@@ -549,9 +547,7 @@ corresponding configuration Nix expression.
 :::
 
 ::: {#ex-partition-scheme-UEFI .example}
-::: {.title}
 **Example: Example partition schemes for NixOS on `/dev/sda` (UEFI)**
-:::
 ```ShellSession
 # parted /dev/sda -- mklabel gpt
 # parted /dev/sda -- mkpart primary 512MB -8GB
@@ -562,9 +558,8 @@ corresponding configuration Nix expression.
 :::
 
 ::: {#ex-install-sequence .example}
-::: {.title}
 **Example: Commands for Installing NixOS on `/dev/sda`**
-:::
+
 With a partitioned disk.
 
 ```ShellSession
@@ -583,9 +578,7 @@ With a partitioned disk.
 :::
 
 ::: {#ex-config .example}
-::: {.title}
 **Example: NixOS Configuration**
-:::
 ```ShellSession
 { config, pkgs, ... }: {
   imports = [