Replaces `community.docker.docker_image` with the modern
`docker_image_pull` and `docker_image_build` split modules across all
four task files (synapse, reverse_proxy_companion, goofys,
rust-synapse-compress-state). Drops the `ansible_version` compatibility
ladder and removes four `_container_image_force_pull` variables (the new
pull module handles registry refresh natively via `pull: always`).

The Synapse self-build path uses `ansible.builtin.shell` for BuildKit
support and is left as-is. The customizations image build (which builds
on top of the locally-tagged synapse image) is converted to
`docker_image_build` with `pull: false`, preserving its existing
rebuild-trigger semantics.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5191.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Register image pull, env, and systemd service results, compute
matrix_goofys_restart_necessary, and wire it into group_vars/matrix_servers
instead of hardcoding restart_necessary: true.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>

We expect `--tags=start` to handle systemd reloading, so we don't need
to do it manually each time we install/uninstall a .service file.

- forego removing Docker images - it's not effective anyway, because it
  only removes the last version.. which is a drop in the bucket, usually

- do not reload systemd - it's none of our business. `--tags=start`,
  etc., handle this

- combine all uninstall tasks under a single block, which only runs if
  we detect traces (a leftover systemd .service file) of the component.
  If no such .service is detected, we skip them all. This may lead to
  incorect cleanup in rare cases, but is good enough for the most part.

This fixes a regression since the change done in c1c152f7ac.
When another role (say `matrix-jitsi`) included `roles/custom/matrix-base/tasks/util/ensure_openssl_installed.yml`,
which then included `{{ role_path }}/tasks/util/ensure_openssl_installed_DISTRO.yml`,
that `role_path` variable would end up being the parent role
(`matrix-jitsi`) and not the `matrix-base` role, so we'd get a failure.

An alternative solution may have been to avoid using `role_path`, but
importing roles properly (like we've done in this patch) sounds like a better way.

Unfortunately, `import_role` fails if `tasks_from` is something like
`util/ensure_openssl_installed` (containing a `/`), so I had to move
these utils out of `util/`.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228

This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.