[Feature] Add resources field under systemInitialization for init containers

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/doris-operator/issues?q=is%3Aissue) and found no similar issues.

### Description

Background
In the current DorisCluster custom resource (CR) definition of the Doris Operator, there is a systemInitialization field (e.g., for customizing init container image, commands, args) but it lacks explicit support for specifying resource requests/limits for the init container(s).

For example (simplified):

```yaml
systemInitialization:
initImage: myrepo/init:latest
command:
- "/bin/sh"
- "-c"
- "echo Initializing…"
args:
- …
# no resources: section currently defined
```

Problem
Without a resources section, init containers run with default scheduler behaviour (which may not align with cluster resource policies or guarantee minimum CPU/memory). This can lead to:
• Init containers being scheduled on nodes with insufficient resources
• Interference with other workloads during initialization
• Lack of control for cluster operators who want to restrict resource consumption of init steps
• In clusters that enforce ResourceQuota, the deployment may even fail because the init container does not declare its resource requests and limits, causing the scheduler or admission controller to reject the Pod.

Suggested enhancement
Add a resources field (of type corev1.ResourceRequirements) under systemInitialization in the CR schema.
Example:

```yaml
systemInitialization:
initImage: myrepo/init:latest
command:
- "/bin/sh"
- "-c"
- "echo Initializing…"
args:
- …
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
```

The operator’s code (in constructDisaggregatedInitContainers or equivalent) should then honour si.Resources when building the init container spec, and only omit the resources section when no resource object is provided.

Benefits
• Gives cluster deployers explicit control over init container resource usage
• Prevents init containers from star­ving or being starved by other pods
• Improves operator flexibility and aligns init containers with other workload best practices

Compatibility / Implementation notes
• Make the resources field optional to preserve backwards compatibility (i.e., when omitted, use current behaviour)
• Update CRD (OpenAPI schema) to include resources under the systemInitialization object
• Update relevant Go types in api/v1 (or wherever SystemInitialization is defined) to add Resources corev1.ResourceRequirements
• Update controller logic (e.g., constructDisaggregatedInitContainers) to set the container’s .Resources only when provided (and not when empty)
• Update documentation and examples (README, sample YAMLs) accordingly

Thank you for considering this enhancement — I believe it will improve the operator’s deployer-experience and align with Kubernetes best-practices for init containers.

### Use case

_No response_

### Related issues

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)