Revert Policy.id back to UUID struct

[annacai21]

#74 changed Policy.id from a UUID struct ({hi:ulong, lo:ulong}) to a string, so RC-delivered policies could carry a real rule UUID instead of an always absent field. This looked backwards-compatible on the read side (FlatBuffers absent-field guarantee covers old binaries being read by new code), but breaks on the compile side: dd-compile-policy's JSON parser has the schema hardcoded in, and there's no current way to remotely update the compiler binary. It's vendored into datadog-agent via a version pin here, not delivered via Remote Config.

I tested against the currently released dd-compile-policy binary (v0.1.13):

• A policy JSON with "id": "<uuid-string>" fails: Failed to parse JSON: ... expecting: { instead got: string constant.
• A policy JSON with any new/unrecognized field (e.g. rule_id) also fails: Failed to parse JSON: ... unknown field: ....

Both failure modes mean any host running an already-deployed dd-compile-policy would start failing to compile policies the moment RC starts emitting the new content in the JSON payload, with no way to force those hosts to upgrade first.

Reverting to the UUID struct avoids this: the field shape is unchanged from what's already deployed everywhere, so instead of a string, the real rule UUID gets encoded into hi/lo.

Hardcoded/built-in policies are identified as hardcoded because they simply omit id.

[datadog-datadog-prod-us1]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 21.66%

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4f36291 | Docs | Datadog PR Page | Give us feedback!}

[natitsechanski]

lgtm