SYSTEM_USER privilege and account categories to protect privileged accounts

Summary

Add a privilege (proposed name SYSTEM_USER, matching MySQL for
compatibility) that classifies accounts into system and regular categories.
A regular account (one that lacks the privilege) must not be able to administer,
drop, or kill sessions belonging to a system account (one that holds it), even
when the regular account holds CREATE USER or equivalent privileges. This
mirrors the account-category model available in MySQL 8.0.16 and later.

Rationale / motivation

MariaDB has done good work splitting SUPER into fine-grained privileges
(READ ONLY ADMIN, CONNECTION ADMIN, BINLOG ADMIN,
REPLICATION SLAVE ADMIN, SET USER, and others) and it supports roles.
However, there is no concept of protected account tiers. Any account holding
CREATE USER (or UPDATE on the mysql database) can create, alter,
rename, drop, and re-grant on any account in the instance, including other
administrators and the most privileged account. There is no engine-enforced way
to protect a privileged account from a less-privileged administrator.

Current behavior

• A regular admin with CREATE USER can DROP, ALTER, RENAME, and
  SET PASSWORD on any account, including the top administrative account.
• A regular admin can KILL sessions and statements owned by privileged accounts.
• A regular admin can create a stored object whose DEFINER points at a
  privileged account.

Proposed behavior

1. An account holding SYSTEM_USER is a system account; an account without it
   is a regular account.
2. SYSTEM_USER grants no capability on its own. It only governs which account
   category the holder's other privileges may act on. Account operations still
   require the relevant underlying privilege (for example CREATE USER).
3. A regular account must not be able to run CREATE USER, ALTER USER,
   RENAME USER, DROP USER, SET PASSWORD, GRANT, or REVOKE
   against a system account. A system account with the appropriate underlying
   privileges may administer both categories.
4. To KILL a connection or query owned by a system account, the caller's
   session must hold SYSTEM_USER in addition to CONNECTION ADMIN (or SUPER).
5. Setting a stored object DEFINER to a system account requires SYSTEM_USER.
6. SYSTEM_USER may be granted directly or via a role. When granted via a role,
   protection applies to a session only while that role is active (session-scoped),
   consistent with MariaDB's role model.
7. GRANT ALL should include SYSTEM_USER (so protected setups explicitly
   REVOKE SYSTEM_USER from regular admins), matching MySQL for portability.
8. Granting or revoking SYSTEM_USER should affect only new sessions for the
   target account, not existing connections.