feat(policy): add policy develop eval

[Piskoo]

This PR adds a new policy eval command to evaluate policies against materials.

Usage

# Evaluate policy against a specific material type
$ chainloop policy devel eval --policy policy.yaml --material sbom.json --kind SBOM_CYCLONEDX_JSON

# Auto-detected kind with material annotations and policy inputs
$ chainloop policy devel eval --policy policy.yaml --material attestation.json \
    --annotation key1=value1,key2=value2 --input key3=value3

Flags
--policy: Path to policy file (required)
--material: Path to material file (required)
--kind: Material type (optional, will auto-detect if omitted)
--annotation: Material annotations (key=value pairs)
--input: Policy inputs (key=value pairs)

Closes #1108

[migmartri]

we also run attestation-type policies. Their evaluation happen on att push. Does this cover this case?

[Piskoo]

Currently only material policies are evaluated, should I add a way choose between material or attestation metadata evaluation?

[migmartri]

Why do you need to chooose? Wouldn't providing kind ATTESTATION would be enough? cc/ @jiparis

[Piskoo]

Found the problem, I'll make it work that way if kind ATTESTATION is detected/passed

[Piskoo]

Went through the existing code again, everything should be working for ATTESTATION in the current implementation.

[jiparis]

Yes, it works like any other material type, it should be supported already.

[javirln]

I think the ignore flag is missign

[jiparis]

Yes, @Piskoo there is a "ignore" flag in evaluation results, that is used for the engine to ignore the policy execution (as it never existed). It's used in cases where the decision logic is in the Rego itself. Not too important for this command though.

[Piskoo]

It's being handled by NoPolicies, I will rename it for consistency

[jiparis]

I think this should be Info() as well. Unless we know what's the user expectation, having Violations is a valid outcome, not an error.

[jiparis]

I like we are using real crafted materials, instead of a simulation.
I'd create a follow up task to extract this functionality in the CLI and use it everywhere instead of duplicating the logic (like the kind autodetect loop, for example).

[jiparis]

Accepted with some minor comments. Thanks.