[Improvement] Add DRY-RUN support to Gravitino API

### What would you like to be improved?

### Summary
Please add a `dry-run` mode to Gravitino API operations that create/update/delete metadata objects and governance bindings.
### Problem
Today, metadata changes are applied directly, which makes it hard to safely validate impact before execution.
For GitOps workflows, teams need a way to preview changes (plan) before apply.
### Proposal
Introduce a dry-run capability (for example via query param/header/flag) that:
- validates request payloads and permissions,
- resolves target objects and dependencies,
- computes the expected diff,
- returns what would change,
- does **not** persist any changes.
### Expected response (example)
For dry-run requests, return structured output such as:
- operation type (`create`, `update`, `delete`),
- target object(s),
- before/after snapshot or field-level diff,
- validation results and warnings,
- dependency/conflict information,
- final status: `would_apply=true/false`.
### Why this is important
- safer production operations,
- better CI/CD and GitOps integration (`plan -> review -> apply`),
- easier change review and approvals,
- simpler rollback planning and auditability.
### Suggested scope
Dry-run support for at least:
- catalogs/schemas/tables/models/topics/filesets,
- tags and policy associations,
- permission/governance-related updates.
### Acceptance criteria
- [ ] API supports dry-run mode for key mutating endpoints.
- [ ] Dry-run never modifies server state.
- [ ] Response includes machine-readable diff/details.
- [ ] Validation and authorization are executed in dry-run.
- [ ] Documentation includes examples and behavior guarantees.

### How should we improve?

_No response_

Start by mapping the Gravitino API's mutating endpoints for metadata objects and governance bindings, then review how validation, authorization, persistence, and responses currently work. Define the dry-run scope and machine-readable response contract before implementation. Done means supported operations validate and report their expected changes without modifying server state, with documentation and examples.

Written by the indexing model from the issue text.