MDEV-40786 make mariadb-plugin great

[MooSayed1]

The Jira issue number for this PR is: MDEV-40786

Description

First step of turning the mariadb-plugin tool into a plugin package
manager, as described in the MDEV. This covers the package-manager half:
RPM and DEB installations. The binary tarball half comes later, as it
needs the plugin metadata on the download site.

mariadb-plugin search [<plugin_name>]
mariadb-plugin install <plugin_name>
mariadb-plugin uninstall <plugin_name>

The legacy <plugin> ENABLE|DISABLE syntax is kept for backward
compatibility: it is recognized on the raw arguments, before any option
parsing, and continues through the original code path unchanged. A command
word wins over the keywords, so search enable searches for "enable"
instead of taking the deprecated path.

Plugin names are normalized to lower case and validated against
[a-z0-9_-] (max 64 chars), since they are used to build package names.

Install-method detection. The install layout (RPM, DEB, tarball) is
compiled in from INSTALL_LAYOUT, as it cannot be derived from the path:
RPM and DEB share the same directories. At runtime the tool locates itself
through argv[0] (my_path() + my_realpath(), which also resolves the
legacy mysql_plugin symlink) and verifies it belongs to that
installation: on RPM/DEB the binary must sit in the compiled-in bindir, on
a tarball the plugin directory must exist under the basedir. A build tree
is therefore not accepted.

Delegation. On RPM and DEB installations install and uninstall
delegate to the system package manager, so plugin files stay owned by it
and dependency resolution, signature checks and upgrades keep working.
apt-get is used on DEB; on RPM dnf is preferred and zypper used when
dnf is absent. Commands run through fork()/execvp() with an argument
vector, never a shell, and inherit the standard streams, so the package
manager prompts the user itself and its exit code is passed through
unchanged. Non-root invocations are rejected before anything is spawned.

uninstall on RPM first resolves the real package name with
rpm -q --whatprovides, because dnf 5 does not accept Provides names for
removal (dnf 4 and zypper do); this also gives a clear message when the
plugin is not installed.

Uniform naming. RPM packages keep their own names
(MariaDB-rocksdb-engine) and get the uniform name as a Provides,
generated per plugin component in cmake/plugin.cmake. DEB packages
already carry it. So the tool knows one naming rule and zero package names.

Search. The distribution's package index is queried for everything
providing mariadb-plugin-* and printed uniformly as plugin name,
installed/available, and description. dnf search ignores Provides, so
repoquery is used; zypper never reports which capability matched, so a
second zypper info --provides call recovers the uniform name. An optional
term filters by substring. Needs no root; exits non-zero when nothing
matches.

--dry-run prints the commands install and uninstall would run,
with the package name resolved, without running them and without needing
root. Long-only, as -n is taken by the legacy --no-defaults.

Still to come: the binary tarball engine (download, checksum, unpack,
file manifest) and tarball search, which needs the plugin index on the
download site.

Release Notes

mariadb-plugin gains search, install and uninstall subcommands. On
RPM and DEB installations they delegate to the system package manager, with
plugins named uniformly as mariadb-plugin-<name> everywhere. A
--dry-run option shows what would be run. The legacy ENABLE|DISABLE
syntax still works and is now deprecated.

How can this PR be tested?

main.mariadb-plugin covers the command line: unknown commands, argument
counts, plugin name validation, and that ENABLE|DISABLE still reaches the
old code path. The delegation itself cannot run under mtr, since the tool
only acts when it runs from the location it was installed to, so it belongs
to the install/upgrade builders.

Manually, with a binary built for the matching layout and placed in the real
bindir:

mariadb-plugin search                 # plugin name, installed/available, description
mariadb-plugin search provider        # filtered
mariadb-plugin --dry-run install rocksdb
mariadb-plugin install rocksdb
mariadb-plugin uninstall rocksdb

Tested in containers:

• Debian trixie against the real Debian repos: all 16 real
  mariadb-plugin-* packages listed, and mariadb-plugin-rocksdb
  installed and removed through the tool.
• Fedora 42 (dnf 5) and openSUSE Tumbleweed (zypper) against a local
  repository of packages built from this branch, so they carry the
  generated Provides: install resolves the uniform name, uninstall
  resolves the real package name, and search lists them.
• Non-root, and running an RPM/DEB-layout binary from the wrong directory,
  both produce a single clear error.

Basing the PR against the correct MariaDB version

This is a new feature, so this PR targets main.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[gkodinov]

Thanks for looking into this. This is nowhere near close to being ready for review. Converting to draft until it's actually delivering towards the specification in the jira.