Support setting cpu_request in cluster replica sizes

[alex-hunt-materialize]

Supports setting cpu_request independently of cpu_limit in cluster replica sizes.

Motivation

Resolves https://github.com/MaterializeInc/database-issues/issues/10100

More context:
https://materializeinc.slack.com/archives/C07PN7KSB0T/p1770215227882419
https://materializeinc.slack.com/archives/C0854GU86HL/p1771932457688129

Description

• Adds support for setting cpu_request independently of cpu_limit in ReplicaAllocation.
• Updates the helm chart values to by default use cpu_request instead of cpu_limit.
• Parses the cluster replica sizes in orchestratord so we can set cpu_limit for older environmentd versions that don't support cpu_request.

Also updates a massive number of our crates to not pull in default features for other crates. This is needed to avoid pulling in workspace hack when default-features=false, to avoid pulling in workspace hack in the cloud repo.

It's easier to review the two commits separately.

Verification

Orchestratord nightly tests should exercise the main code change, but I'm running all of them due to the default features changes.

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• 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).