Standardizing driver SYNOPSIS sections

Hello,

I would like to standardize the SYNOPSIS syntax of driver manuals to
remove prose, following the example set in vt(4) since 12 years ago.

Upstream specifies driver SYNOPSIS to only include kernel declarations
usable in config(8), one on each line. However, we traditionally also
cram extra types of kernel configurations in there, like rc.conf, and
resort to prose to clarify this. The issue with this is that it
undermines the consistency of the entire manual conventions, where
elsewhere SYNOPSIS simply enumerates usage.

The end result is that we will increase consistency by describing usage
in DESCRIPTION, like all other sections of the manual, increasing new
reader comprehension as well as elegance, and greater standardization.
The experienced operator who is familiar with the manual already could
more rapidly check syntax, as well as get to the DESCRIPTION faster.

The vt(4) manual uses more closely follows mdoc(7) and other BSDs style,
while optionally subsequently allowing our convention of putting "extra"
information in, like sysctls, in a very neat and terse way:

    SYNOPSIS
        options $option_available_in_kernconf1
        options $option_available_in_kernconf2
        device $required_device_in_kernconf1
        device $required_device_in_kernconf2

    In loader.conf(5):
        here.is.a.sysctl=?
        here.is.another=?

We have 176 driver manuals already following this style, and 399 which
do not.

There are two known issues not addressed by what is already in vt(4):

1. These are written using .Cd (kernel configuration declaration). This
currently is specified in mdoc(7) to apply exlusively to kernconf lines
that could be used in config(8).

I propose we extend the usage of the Cd macro to cover all kernel
configuration in SYNOPSIS, matching what is already in our manuals
(see draft patch). Other macros are not suitable due to formatting.

2. We have kernel modules. They are sometimes not named consistently
with the name of the driver in question or the manual page. One of the
uses of the prose we traditionally use is to explain the name of the
required module.

I propose that we specify the name of the module in the NAME section
onlyif it is different. This is a bit ugly, but at least it is
consistent and predictable. For example:

    NAME
        ahc, ahc_isa.ko, ahc_pci.ko - Adaptec SCSI host adapter driver

To migrate, I suggest that we first update share/examples/example.4 and
contrib/mdoc.7, then the FDP, then we allow manuals to be rewritten in
this style gradually.

I have posted a WIP patch on Phabricator for the first portion [1].

I also gave a talk on this at BSDCan '25, and upstream had some
interesting comments in the comments section [1].

This is not completely bulletproof perfect, but it is a big step forward
in consistency and predictability from what we have, without being quite
invasive.

[0]: https://reviews.freebsd.org/D54586
[1]: https://youtu.be/RthIOXpwwsM