[FEATURE] Split MODIFY_TABLE privilege into INSERT_TABLE and ALTER_TABLE for finer-grained access control

### Describe the feature

Currently, `MODIFY_TABLE` is a coarse-grained privilege that bundles write data operations (INSERT, UPDATE, DELETE) and schema modification (ALTER TABLE) into a single permission. This makes it impossible to grant a user the ability to write data without also granting schema modification rights, or vice versa.

We propose introducing finer-grained table privileges:

- `INSERT_TABLE` — write rows to a table (INSERT, INSERT OVERWRITE)
- `DELETE_TABLE` — delete rows from a table
- `ALTER_TABLE` — modify table schema (ADD/DROP/RENAME COLUMN, partition changes, etc.)
- `DROP_TABLE` — drop a table (currently only controllable via Ownership)

### Motivation

In real-world data platforms, different user groups require different levels of access:

- **ETL jobs / data pipelines**: need `INSERT_TABLE` to write data, but should NOT be allowed to alter table schemas
- **Schema owners / data engineers**: need `ALTER_TABLE` for schema evolution, independent from data write access
- **Compliance workflows**: `DELETE_TABLE` (e.g., GDPR right-to-erasure) requires explicit separate approval and should not be bundled with INSERT/UPDATE

The current `MODIFY_TABLE` mapping in the JDBC authorization plugin translates to `SELECT + UPDATE + DELETE + INSERT + ALTER` — granting all of these together whenever a user needs write access. This violates the **principle of least privilege**.

Industry-standard systems distinguish these operations:

| System | Write Data | Modify Schema |
|---|---|---|
| Apache Ranger (Hive) | `UPDATE` / `WRITE` | `ALTER` |
| Apache Hive native | `INSERT` | `ALTER` |
| Trino | `INSERT` / `UPDATE` | `ALTER` |
| MySQL / OceanBase | `INSERT` / `UPDATE` / `DELETE` | `ALTER` |
| ClickHouse | `INSERT` | `ALTER TABLE` |

Additionally, the internal EasyData client in `catalog-hive` already maps to granular permissions (`insert`, `update`, `delete`, `alter`) at the data source level — but Gravitino's public `Privilege.Name` enum cannot express this distinction, resulting in information loss at the abstraction layer.

### Describe the solution

Add the following new `Privilege.Name` enum values:

```java
INSERT_TABLE(0L, 1L << X), // Write rows to a table
DELETE_TABLE(0L, 1L << Y), // Delete rows from a table
ALTER_TABLE(0L, 1L << Z), // Modify table schema
DROP_TABLE(0L, 1L << W), // Drop a table
```

Keep `MODIFY_TABLE` unchanged for **full backward compatibility** — existing roles and integrations are not affected.

Authorization plugin mapping updates:

| New Privilege | Ranger (HadoopSQL) | JDBC (MySQL / OceanBase / Doris / ClickHouse) |
|---|---|---|
| `INSERT_TABLE` | `UPDATE`, `WRITE` | `INSERT` |
| `DELETE_TABLE` | `UPDATE` | `DELETE` |
| `ALTER_TABLE` | `ALTER` | `ALTER` |
| `DROP_TABLE` | `DROP` | `DROP` |

All new privileges support binding to: `Metalake`, `Catalog`, `Schema`, `Table` — consistent with existing `MODIFY_TABLE` and `SELECT_TABLE`.

### Additional context

_No response_

Start with the Privilege.Name enum and the existing MODIFY_TABLE mappings in the authorization plugins, then compare the granular permissions already described for catalog-hive. Trace the Ranger and JDBC mapping points and the supported Metalake, Catalog, Schema, and Table bindings. Done means the four privileges are represented and mapped while MODIFY_TABLE remains backward compatible.

Written by the indexing model from the issue text.