feat: add upgrade window check for environmentd image ref

[SangJunBak]

This commit introduces a new method to check if the current environmentd image reference is within the upgrade window of the last successful rollout. We default the image ref to the current version if status is not set.

Not sure if this is the best way to solve this! One nice thing is we'll see the last version everytime we upgrade which can be useful.

An edge case is if the user's materialize CR status is already set, then it won't have last_completed_rollout_environmentd_image_ref until the next successful rollout. So hypothetically, users on v26.0.0 can jump straight to v28.0.0 if they didn't upgrade between then.

We solve this by relaxing the check as much as possible, also in case of other false positives.

Motivation

• This PR adds a known-desirable feature.
• https://github.com/MaterializeInc/database-issues/issues/9860

Tips for reviewer

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.

[doy-materialize]

conceptually this seems fine, but can we reuse the existing logic for checking the version compatibility? we already have an implementation of this in cloud via is_valid_upgrade_image_ref, and i think it'd be better to pull that code out to the materialize repo and use it in both places

[SangJunBak]

@doy-materialize done in the latest commit and created a followup cloud PR https://github.com/MaterializeInc/cloud/pull/11901. More or less copied the code and tests. Two things:

1. Noticed the cloud check is a bit more restrictive than my check. Specifically, I kind of feel like we shouldn't outright deny upgrades to dev versions in the materialize CR.
2. How does the flow for making an update to the cloud repo after making a change to the materialize repo work? Do I need to wait for a stable release or can I just update the submodule ref?