adapter: Add OfflineReason::Initializing for cluster replicas

[ParkMyCar]

This PR adds an new offline reason for cluster replicas of "initializing". When the DDL that creates a new cluster replica completes, that replica starts with a status of offline and a reason: null, once Kubernetes creates the replica it gets updates to a status of online.

This change should make that initializing period more obvious.

Motivation

We recently saw an issue where the mz_internal.mz_cluster_replica_statuses history was incorrect, and I'm hoping this PR should help us debug the issue a bit further if we see it again. (Slack)

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.

[jkosh44]

LGTM