### 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
- "The user dbus process is normally started during normal login, but not during the run of Ansible tasks.
              Otherwise you will probably get a 'Failed to connect to bus: no such file or directory' error."
            - The user must have access, normally given via setting the C(XDG_RUNTIME_DIR) variable, see example below.
        type: str
        choices: [ system, user, global ]
        default: system
        version_added: "2.7"
    no_block:
        description:
            - Do not synchronously wait for the requested operation to finish.
              Enqueued job will continue without Ansible blocking on its completion.
        type: bool
        default: no
        version_added: "2.3"
extends_documentation_fragment: action_common_attributes
attributes:
    check_mode:
        support: full
    diff_mode:
        support: none
    platform:
        platforms: posix
notes:
    - Since 2.4, one of the following options is required O(state), O(enabled), O(masked), O(daemon_reload), (O(daemon_reexec) since 2.8),
      and all except O(daemon_reload) and (O(daemon_reexec) since 2.8) also require O(name).
    - Before 2.4 you always required O(name).
    - Globs are not supported in name, i.e C(postgres*.service).
    - The service names might vary by specific OS/distribution
    - The order of execution when having multiple properties is to first enable/disable, then mask/unmask and then deal with service state.
      It has been reported that systemctl can behave differently depending on the order of operations if you do the same manually.