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. New CLI surface:

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 detected on the raw arguments (is_legacy_syntax()),
before any option parsing, and continues through the original code path
completely unchanged. The usage text marks it as deprecated.

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

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.

Package-manager 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 is 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 produces a clear message
when the plugin is not installed.

Still to come on this PR: Provides: mariadb-plugin-<X> on the RPM
packages (so the uniform name resolves against mariadb.org packages),
search, and tarball support.

Release Notes

mariadb-plugin gains search, install and uninstall subcommands
(work in progress). On RPM and DEB installations install and
uninstall delegate to the system package manager. The legacy
ENABLE|DISABLE syntax still works and is now marked deprecated.

How can this PR be tested?

Manual for now (mtr and autopkgtest coverage planned in a follow-up
commit).

CLI surface, any build:

mariadb-plugin install                # error + usage, exit 1
mariadb-plugin banana foo             # unknown command error, exit 1
mariadb-plugin install 'Rock$db'      # name validation error, exit 1
mariadb-plugin install ROCKSDB        # normalized to 'rocksdb'
mariadb-plugin foo ENABLE             # legacy path: original behavior
mariadb-plugin --help                 # new usage, legacy marked deprecated

Delegation needs a binary built with the matching layout, installed in
the real bindir. Tested in containers:

• Debian trixie, -DINSTALL_LAYOUT=DEB: mariadb-plugin install rocksdb
  and uninstall rocksdb install and remove the real
  mariadb-plugin-rocksdb package; an unknown plugin returns apt's own
  error and exit code.
• Fedora 42 (dnf 5) and openSUSE Tumbleweed (zypper),
  -DINSTALL_LAYOUT=RPM, with a local repository providing a package
  with Provides: mariadb-plugin-test: install resolves the alias,
  uninstall resolves the real name and removes it, and uninstalling a
  plugin that is not installed reports it plainly.
• 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.