Replace third-party MAAS role with a DeepOps-owned controller role

[dholt]

Summary

• Replace the third-party Galaxy MAAS role with a DeepOps-owned maas-controller role covering exactly the surface this repository uses: MAAS PPA, package install, idempotent admin-account creation, and region controller URL configuration (~70 lines).
• Why: the Galaxy role has had no functional MAAS changes since 2023; DeepOps exercised roughly six of its eighteen tasks; and its pip installation of unmaintained MAAS client modules — which DeepOps never uses — fails on Ubuntu 24.04 (PEP 668 externally-managed environments), blocking MAAS 3.7 on Noble controllers. Long-lived checkouts additionally risk running a stale on-disk copy of the role that predates the requirements pin and cannot execute on current Ansible at all.
• Drop-in compatible: variable names are unchanged for existing site configs, and the same admin-created marker file is honored so existing deployments do not re-create accounts. The unused maas_setup_user / maas_kvm_management / maas_python_reqs knobs are removed from the example config. The Galaxy dependency is removed from roles/requirements.yml.

Validation

• Full role lint (0 failures); playbooks/provisioning/maas.yml syntax check passes with the Galaxy role uninstalled — the dependency is genuinely gone.
• Live MAAS smoke on a GPU server (Ubuntu 22.04): install and configuration via the new role (ok=7, failed=0), all MAAS services active, API responding (version 3.5.13, full capability list).

Notes

• Multi-node region/rack topologies were never exercised by this repository and are explicitly out of scope (the role asserts single-node mode); sites needing them should follow upstream MAAS documentation.
• Ubuntu 24.04 / MAAS 3.7 controller validation is planned for the current release train; this change removes the known blocker.