Generate enums for operators and overloads

[hudlow]

• Random overload IDs
  After staring at the schema I'm proposing that we generate UUIDs for overload_id values at compile time.

  It basically seems like a bug to me that other implementations treat these as non-opaque values when their stated purpose is purely for cross-referencing values in a compiled expression payload. Using non-opaque IDs, let alone specific, stable non-opaque IDs does not seem to be part of the contract.

  And I believe it should be avoided because of the potential for unintentional collisions that could cause subtle-but-nasty bugs. The best way to avoid depending on the semantics or stability of values is to randomize them.

• Cross-type numeric comparisons
  Where we need to treat specific overloads specially, I have instead proposed a mechanism for standardized flags, and added CelOverloadFlag.CROSS_TYPE_NUMERIC_COMPARISON as the inaugural flag. I've also added a synthetic isCrossTypeNumericComparison property to overloads and a test to verify that the overloads — and only those overloads — that we expect to return true for this property do so.

• Stale generated files
  The operator_const.ts and overload_const.ts files were previously generated... but generated from some hand-maintained YAML files? The generation mechanism and source YAML files have been lost in refactors.

  I've added code that generates these from cel-go to the cel-spec build, and now import these enumerations from that package.

[hudlow]

It seems like crypto is safe to use everywhere?

[timostamm]

"Widely available" according to mdn. Safe to use. https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID

[srikrsna-buf]

I see that this is only used in tests can we move this to the test file?

[hudlow]

Mostly superseded by #244, but some automation is probably worth keeping.