feat: support ordered container start using initContainers (#291)

[Abhishek9639]

Description

This PR adds support for the before property in score-k8s by mapping it to Kubernetes native initContainers, as described in #291.

Currently score-k8s doesn't handle the before field at all. With this change, containers that declare before entries are automatically classified and placed into spec.initContainers instead of spec.containers in the generated manifest.

The mapping follows the approach discussed in the issue:

• ready: complete → regular initContainer (runs to completion before main containers start)
• ready: started → sidecar initContainer with restartPolicy: Always (starts before main containers, keeps running)
• ready: healthy → rejected with a validation error, since K8s initContainers don't support health-based gating natively

Closes #291

What does this PR do?

• Updates score-go from v1.13.0 to v1.15.0 to get the ContainerBefore types
• Adds a validateContainerBefore() function that checks for self-references, unknown containers, cycles, and rejects ready: healthy
• Modifies the workload conversion to split containers into initContainers vs regular containers based on their before entries
• Adds 8 new tests covering both the conversion logic and validation edge cases

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• I've signed off with an email address that matches the commit author.

[Abhishek9639]

Hey @mathieu-benoit,
This is my implementation for the ordered container start feature. I followed the approach discussed in the issue mapping before entries to Kubernetes initContainers, with restartPolicy: Always for sidecars (ready: started) and a validation error for ready: healthy since K8s doesn't support health-based gating on init containers.

I also added cycle detection and other validations similar to how it's done in score-compose.
Let me know if anything needs to be adjusted.
Thanks

[mathieu-benoit]

Thanks, let's make sure we review and approve this one score-spec/score-compose#454 first, and we'll all tackle this one then.

[Abhishek9639]

Got it, that makes sense. I’ll wait for score-spec/score-compose#454 to be reviewed and approved first, then we can proceed with this one.
Thanks

[mathieu-benoit]

@Abhishek9639, now that score-spec/score-compose#454 is approved and merged, anything here to update before our review?

[Abhishek9639]

Hi @mathieu-benoit,
I've already updated score-go to the official v1.16.0 release and the branch is synced with main.
Everything looks good from my end the PR is ready for your review whenever you are.
Thanks

[Abhishek9639]

Hey @mathieu-benoit,
Now that score-spec/score-compose#454 is merged, I think this one should be good to pick up next. I've synced the branch with main and everything's passing on my end. Whenever you get a chance to take a look, I'm around if anything needs adjusting.
Thanks!

[Abhishek9639]

Hey @mathieu-benoit,
Just resolved the merge conflict in internal/command/generate_test.go (it was just my new before tests and the new KYAML/format tests from main landing in the same spot, so I kept both). Branch is synced with main again and everything's passing on my end. Should be good for review whenever you get a chance, happy to adjust anything if needed.
Thanks!