Restore semantic links now the targets exist

Author: ncoghlan

source/discussions/single-source-version.rst

@@ -10,7 +10,7 @@ Single-sourcing the Project Version
 Many Python :term:`distribution packages <Distribution Package>` publish a single
 Python :term:`import package <Import Package>` where it is desired that the runtime
 ``__version__`` attribute on the import package report the same version specifier
-as :func:`!importlib.metadata.version` reports for the distribution package
+as :func:`importlib.metadata.version` reports for the distribution package
 (as described in :ref:`runtime-version-access`).
 
 It is also frequently desired that this version information be derived from a version

source/discussions/versioning.rst

@@ -178,7 +178,7 @@ Accessing version information at runtime
 
 Version information for all :term:`distribution packages <Distribution Package>`
 that are locally available in the current environment can be obtained at runtime
-using the standard library's :func:`!importlib.metadata.version` function::
+using the standard library's :func:`importlib.metadata.version` function::
 
    >>> importlib.metadata.version("cryptography")
    '41.0.7'
@@ -235,7 +235,7 @@ multiple ways to access the underlying OpenSSL library version::
 .. [#fallback-to-dist-version] A full list mapping the top level names available
    for import to the distribution packages that provide those import packages and
    modules may be obtained through the standard library's
-   :func:`!importlib.metadata.packages_distributions` function. This means that
+   :func:`importlib.metadata.packages_distributions` function. This means that
    even code that is attempting to infer a version to report for all importable
    top-level names has a means to fall back to reporting the distribution
    version information if no ``__version__`` attribute is defined. Only standard