adapter: replacement materialized views

[teskje]

This PR implements an MVP enabling replacement of materialized views. It follows the same ideas as #34032 but models replacement MVs as special MVs instead of introducing a separate catalog item type. This matches the product requirements we arrived at in this Slack thread but doesn't currently match the design doc (I'm planning to fix that soon).

The PR adds the following syntax:

-- To replace a materialized view, the user creates a replacement:
CREATE MATERIALIZED VIEW mv_replacement REPLACING mv AS SELECT ...;
-- The user then observes hydration progress.
-- At some point, they decide it wasn't a good change after all:
DROP MATERIALIZED VIEW mv_replacement;
-- Or, they figure it's a good change and apply it:
ALTER MATERIALIZED VIEW mv APPLY REPLACEMENT mv_replacement;

Modelling replacement MVs as materialized views means that the amount of code changes required is much less than in the alternative approach that introduces a new item type. It also means that diagnostic queries that work for MVs also immediately work for replacements, including SHOW CREATE, EXPLAIN, and EXPLAIN ANALYZE.

There are a few special cases of replacement MVs that this PR doesn't address yet:

• It shouldn't be possible to select from replacements.
• It shouldn't be possible to create objects that depend on replacements.
• It shouldn't be possible to have more than one replacement for the same MV.
• Comments on replacements should overwrite comments on the target MV when the replacement is applied.

All of these are left as follow ups.

Motivation

• This PR adds a known-desirable feature.

Part of https://github.com/MaterializeInc/database-issues/issues/9903

Tips for reviewer

Commits are meaningful and can be reviewed individually.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[teskje]

Note that currently it's possible to panic envd by creating an MV that depends on itself, like this:

CREATE TABLE t (a int);
CREATE MATERIALIZED VIEW mv AS SELECT * FROM t;
CREATE MATERIALIZED VIEW rp REPLACING mv AS SELECT * FROM mv;
ALTER MATERIALIZED VIEW mv APPLY REPLACEMENT rp;

Though this doesn't actually do anything cool, just panics envd 😞 I'll fix this in a follow-up as well.