…tadata (apache#65644)

Issue apache#65479

Kernel plugin families (filesystem, connector, authentication, lineage)
currently have no unified, queryable inventory: to know which plugins
are loaded on an FE, one has to read logs. This PR adds a unified
`information_schema.plugins` system table listing all successfully
loaded kernel plugins of the currently connected FE.

Columns: `PLUGIN_NAME`, `PLUGIN_TYPE`, `PLUGIN_VERSION`, `SOURCE`,
`DESCRIPTION`.

Design points:
- `(plugin_type, plugin_name)` is the primary key, enforced at load
time: the first registration wins and is never silently overridden, so a
directory jar can never displace a built-in plugin.
- `name()` / `description()` are snapshotted once at load time; querying
the table never executes plugin code. A broken self-report fails the
load.
- Plugin names are validated at load (trimmed, non-blank, <=64 chars,
`[A-Za-z0-9._-]`); an invalid name fails the load for external plugins.
- `PLUGIN_VERSION` comes from the jar MANIFEST `Implementation-Version`
(NULL when unavailable), never from plugin interface methods.
- Only successfully loaded plugins appear; load failures go to logs. No
status/fail_reason columns.
- Querying requires global ADMIN privilege; non-admin users see no rows.
- View semantics are per-FE: the BE scanner RPCs the currently connected
FE (same pattern as `catalog_meta_cache_statistics`), so per-FE jar
deployment can be audited connection by connection.

Implementation:
- `fe-extension-spi`: add `default String description()` to
`PluginFactory` (empty by default, zero migration cost).
- `fe-extension-loader`: new process-wide `PluginRegistry` (load-time
snapshots only) and `PluginNames` validation;
`DirectoryPluginRuntimeManager` snapshots name/description and reads
`Implementation-Version` from the jar containing the factory class.
- The four family managers register BUILTIN/EXTERNAL rows; filesystem
and connector managers now also reject external providers whose name
conflicts with an already-registered one.
- FE: `SchemaTable` definition + `MetadataGenerator` data source; thrift
`TSchemaTableName.PLUGINS`. Reuses the existing MySQL-compat
`TSchemaTableType.SCH_PLUGINS`.
- BE: new `schema_plugins_scanner` wired into `schema_scanner`.

Example:

```
mysql> SELECT * FROM information_schema.plugins;
+-------------+----------------+----------------+---------+---------------------------+
| PLUGIN_NAME | PLUGIN_TYPE    | PLUGIN_VERSION | SOURCE  | DESCRIPTION               |
+-------------+----------------+----------------+---------+---------------------------+
| hdfs        | FILESYSTEM     | NULL           | BUILTIN |                           |
| jdbc        | CONNECTOR      | NULL           | BUILTIN |                           |
| oidc        | AUTHENTICATION | 4.0.0          | EXTERNAL| OIDC authentication       |
+-------------+----------------+----------------+---------+---------------------------+
```

Add `information_schema.plugins` system table listing loaded kernel
plugins (filesystem/connector/authentication/lineage) of the currently
connected FE; requires ADMIN privilege.

- Test
- [x] Unit test: `PluginRegistryTest`,
`DirectoryPluginRuntimeManagerMetadataTest`
- [x] Regression test:
`regression-test/suites/query_p0/schema_table/test_plugins_schema.groovy`

- Behavior changed:
    - [x] Yes, new `information_schema.plugins` table (additive only).

- Does this need documentation?
- [x] Yes, `information_schema.plugins` should be documented as a new
system table.

(cherry picked from commit 0c35a6e)