sql: add CREATE METRIC SINK as a durable catalog object (SQL-554)

[mtabebe]

Problem:

To maintain cluster metrics we defined the MetricSink compute operator. However, there is no way to ask for one. We need a SQL surface that names a metric sink and a durable catalog representation that survives a restart.

Solution:

Add CREATE METRIC SINK <name> IN CLUSTER <c> FROM <rel> and DROP METRIC SINK, gated behind enable_metric_sink. Creating a sink writes a catalog item and nothing else: no dataflow is optimized or shipped, so a sink created today publishes no metrics.

Planning checks that the FROM relation exposes the five columns the operator reads (metric_name, metric_type, labels, value, help). Note: order is not enforced and extra columns are fine. Nullability is not checked.

Metric sinks need no new durable record. They persist as ordinary Items and item_type works the type out from create_sql.

However, the changes to audit and serialization does bump the catalog version.

There are some gaps in:

• mz_comments has no MetricSink branch, but CommentObjectType has no variant either, so COMMENT ON METRIC SINK does not parse and no such record can exist
• MZ_DEFAULT_PRIVILEGES has no CASE arm, but ON METRIC SINKS is rejected during planning

Note: enable_metric_sink is off by default

Testing:

• New test/sqllogictest/metric_sink.slt: the column contract and each way of violating it, FROM targets with no rows to read, IF NOT EXISTS, the flag-off refusal, and the seven views above answering with
  a metric sink present.

Note to reviewers: The most important files to look at are:

• ddl.rs which has the actual plan for create/drop metric sink
• create_metric_sink.rs which writes the catalog item
• objects.rs which defines the item_type
• mz_catalog.rs small tweak here
• rbac.rs/acl.rs for privilege handling
• lib.rs/jsonb.rs for audit logging
• v90_to_v91.rs the no-op migration
• metric_sink.slt for what is expected behaviour

The rest is threading this all through