### Summary

The [list of builtin modules](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html) shows two modules with similar names and identical descriptions:

> [systemd module](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/systemd_module.html#ansible-collections-ansible-builtin-systemd-module) – Manage systemd units
> [systemd_service module](https://docs.ansible.com/ansible/latest/collections/ansible/builtin/systemd_service_module.html#ansible-collections-ansible-builtin-systemd-service-module) – Manage systemd units

My guess was that `systemd_service` would manage services running with systemd, and `systemd` would manage `systemd` itself. But the description is identical. The synopsis is identical. The arguments and examples appear identical.

As a user, I expect that if one module has two names, the documentation would state that one is an alias.

Looking at [the code](https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/systemd.py) I see that `systemd` is symlinked to `systemd_service.py`.

Please modify the documentation to state that one is an alias of the other, and they are identical.


### Issue Type

Documentation Report

### Component Name

systemd_service

### Ansible Version

```console
N/A
```


### Configuration

```console
N/A
```


### OS / Environment

N/A

### Additional Information

For context, my objective is to create a service file, and then enable+start it. I was hoping that there would be one module to do that. But then I saw there are two similar ones, and I thought one would create the .service file, and the other would load+run it. But that doesn't appear to be the case either.

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct
from __future__ import absolute_import, division, print_function
__metaclass__ = type
DOCUMENTATION = '''
module: systemd_service
author:
    - Ansible Core Team
version_added: "2.2"
short_description:  Manage systemd units
description:
    - Controls systemd units (services, timers, and so on) on remote hosts.
options:
    name:
        description:
            - Name of the unit. This parameter takes the name of exactly one unit to work with.
            - When no extension is given, it is implied to a C(.service) as systemd.
            - When using in a chroot environment you always need to specify the name of the unit with the extension. For example, C(crond.service).
        type: str
        aliases: [ service, unit ]
    state:
        description:
            - V(started)/V(stopped) are idempotent actions that will not run commands unless necessary.
              V(restarted) will always bounce the unit.
              V(reloaded) will always reload and if the service is not running at the moment of the reload, it is started.
        type: str
        choices: [ reloaded, restarted, started, stopped ]
    enabled:
        description: