docs: use anonymous links when possible

Anonymous links has some benefits in that it reduces the chance of
warnings when similar identifiers are used. So let's use them instead
when we can.

Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19492>

docs/ci/LAVA.rst

@@ -1,7 +1,7 @@
 LAVA CI
 =======
 
-`LAVA <https://lavasoftware.org/>`_ is a system for functional testing
+`LAVA <https://lavasoftware.org/>`__ is a system for functional testing
 of boards including deploying custom bootloaders and kernels.  This is
 particularly relevant to testing Mesa because we often need to change
 kernels for UAPI changes (and this lets us do full testing of a new

docs/ci/docker.rst

@@ -3,7 +3,7 @@ Docker CI
 
 For LLVMpipe and Softpipe CI, we run tests in a container containing
 VK-GL-CTS, on the shared GitLab runners provided by `freedesktop
-<http://freedesktop.org>`_
+<http://freedesktop.org>`__
 
 Software architecture
 ---------------------
@@ -53,7 +53,7 @@ step across multiple test runs.  Since the images are large and change
 approximately weekly, the DUTs also need to be running some script to
 prune stale Docker images periodically in order to not run out of disk
 space as we rev those containers (perhaps `this script
-<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`_).
+<https://gitlab.com/gitlab-org/gitlab-runner/issues/2980#note_169233611>`__).
 
 Note that Docker doesn't allow containers to be stored on NFS, and
 doesn't allow multiple Docker daemons to interact with the same

docs/ci/index.rst

@@ -191,7 +191,7 @@ Docker caching
 The CI system uses Docker images extensively to cache
 infrequently-updated build content like the CTS.  The `freedesktop.org
 CI templates
-<https://gitlab.freedesktop.org/freedesktop/ci-templates/>`_ help us
+<https://gitlab.freedesktop.org/freedesktop/ci-templates/>`__ help us
 manage the building of the images to reduce how frequently rebuilds
 happen, and trim down the images (stripping out manpages, cleaning the
 apt cache, and other such common pitfalls of building Docker images).
@@ -211,7 +211,7 @@ When developing a given change to your Docker image, you would have to
 bump the tag on each ``git commit --amend`` to your development
 branch, which can get tedious.  Instead, you can navigate to the
 `container registry
-<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`_ for
+<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`__ for
 your repository and delete the tag to force a rebuild.  When your code
 is eventually merged to main, a full image rebuild will occur again
 (forks inherit images from the main repo, but MRs don't propagate

docs/ci/local-traces.rst

@@ -3,10 +3,10 @@ Running traces on a local machine
 
 Prerequisites
 -------------
-- Install `Apitrace <https://apitrace.github.io/>`_
-- Install `Renderdoc <https://renderdoc.org/>`_ (only needed for some traces)
-- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`_ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`_
-- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`_
+- Install `Apitrace <https://apitrace.github.io/>`__
+- Install `Renderdoc <https://renderdoc.org/>`__ (only needed for some traces)
+- Download and compile `Piglit <https://gitlab.freedesktop.org/mesa/piglit>`__ and install his `dependencies <https://gitlab.freedesktop.org/mesa/piglit#2-setup>`__
+- Download traces you want to replay from `traces-db <https://gitlab.freedesktop.org/gfx-ci/tracie/traces-db/>`__
 
 Running single trace
 --------------------
@@ -16,7 +16,7 @@ A simple run to see the output of the trace can be done with
 
     apitrace replay -w name_of_trace.trace
 
-For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`_.
+For more information, look into the `Apitrace documentation <https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown>`__.
 
 For comparing checksums use:
 

docs/ci/skqp.rst

@@ -1,9 +1,9 @@
 SkQP
 ====
 
-`SkQP <https://skia.org/docs/dev/testing/skqp/>`_ stands for SKIA Quality
+`SkQP <https://skia.org/docs/dev/testing/skqp/>`__ stands for SKIA Quality
 Program conformance tests.  Basically, it has sets of rendering tests and unit
-tests to ensure that `SKIA <https://skia.org/>`_ is meeting its design specifications on a specific
+tests to ensure that `SKIA <https://skia.org/>`__ is meeting its design specifications on a specific
 device.
 
 The rendering tests have support for GL, GLES and Vulkan backends and test some