docs: consistent headings

Base heading is level 2, which is identical to the level 1.  However
level 3 will be indendet which is used a lot in the `## EXAMPLES`
sections.

Signed-off-by: Valentin Rothberg <vrothberg@suse.com>

Closes: #1375
Approved by: rhatdan

docs/containers-mounts.conf.5.md

@@ -1,15 +1,15 @@
 % containers-mounts.conf(5)
 
-# NAME
+## NAME
 containers-mounts.conf - configuration file for default mounts in containers
 
-# DESCRIPTION
+## DESCRIPTION
 The mounts.conf file specifies volume mount directories that are automatically mounted inside containers. Container processes can then use this content. Usually these directories are used for passing secrets or credentials required by the package software to access remote package repositories. Note that for security reasons, tools adhering to the mounts.conf are expected to copy the contents instead of bind mounting the paths from the host.
 
-# FORMAT
+## FORMAT
 The format of the mounts.conf is the volume format `/SRC:/DEST`, one mount per line. For example, a mounts.conf with the line `/usr/share/secrets:/run/secrets` would cause the contents of the `/usr/share/secrets` directory on the host to be mounted on the `/run/secrets` directory inside the container. Setting mountpoints allows containers to use the files of the host, for instance, to use the host's subscription to some enterprise Linux distribution.
 
-# FILES
+## FILES
 Some distributions may provide a `/usr/share/containers/mounts.conf` file to provide default mounts, but users can create a `/etc/containers/mounts.conf`, to specify their own special volumes to mount in the container.
 
 ## HISTORY

docs/libpod.conf.5.md

@@ -1,13 +1,13 @@
 % libpod.conf(5)
 
-# NAME
+## NAME
 libpod.conf - libpod configuration file
 
-# DESCRIPTION
+## DESCRIPTION
 The libpod.conf file is the default configuration file for all tools using
 libpod to manage containers.
 
-# OPTIONS
+## OPTIONS
 
 **image_default_transport**=""
   Default transport method for pulling and pushing images
@@ -45,7 +45,7 @@ libpod to manage containers.
 **cni_plugin_dir**=""
   Directories where CNI plugin binaries may be located
 
-# FILES
+## FILES
 /etc/containers/libpod.conf, default libpod configuration path
 
 ## HISTORY

docs/podman-history.1.md

@@ -89,9 +89,6 @@ b676ca55e4f2c   9 weeks ago
 ]
 ```
 
-## history
-Show the history of an image
-
 ## SEE ALSO
 podman(1), crio(8)
 

docs/podman-pod.1.md

@@ -6,7 +6,7 @@ podman\-pod - Simple management tool for groups of containers, called pods.
 ## SYNOPSIS
 **podman pod** *subcommand*
 
-# DESCRIPTION
+## DESCRIPTION
 podman pod is a set of subcommands that manage pods, or groups of containers.
 
 ## SUBCOMMANDS

docs/podman-run.1.md

@@ -738,7 +738,7 @@ The default working directory for running binaries within a container is the roo
 The image developer can set a different default with the WORKDIR instruction. The operator
 can override the working directory by using the **-w** option.
 
-# Exit Status
+## Exit Status
 
 The exit code from `podman run` gives information about why the container
 failed to run or why it exited.  When `podman run` exits with a non-zero code,

docs/podman.1.md

@@ -6,7 +6,7 @@ podman - Simple management tool for containers and images
 ## SYNOPSIS
 **podman** [*options*] *command*
 
-# DESCRIPTION
+## DESCRIPTION
 podman is a simple client only tool to help with debugging issues when daemons
 such as CRI runtime and the kubelet are not responding or failing. A shared API
 layer could be created to share code between the daemon and podman. podman does not