storage: move methods from StorageController to StorageCollections

[aljoscha]

Work towards implementing https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/20240117_decoupled_storage_controller.md. This design document is nice and small, and should help to explain the long-term motivations for those changes.

Prompted by a recent PR from @petrosagg (#30729), I went back to implement some of the easier changes I had in mind for moving towards the design linked above.

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.

[def-]

Nightly triggered: https://buildkite.com/materialize/nightly/builds/10836

I assume this should have no behavioral differences and is well exercised by existing tests, so no new tests required.

[aljoscha]

I assume this should have no behavioral differences and is well exercised by existing tests, so no new tests required.

yep!