Fixes an issue where certain cedar policies couldn't be converted to JSON

[aaronjeline]

Description of changes

Previously, the Cedar EST code would fail to generate an EST for any policy containing the constant -9223372036854775808 (i64::MIN). This happened because it was turned into the CST representing the unary op - applied to the constant 9223372036854775808, which outside the range of i64. This adds a tiny pass to ensure that unary op is constant folded.

Issue #, if available

#596

Checklist for requesting a review

The change in this PR is (choose one, and delete the other options):

• A bug fix or other functionality change requiring a patch to cedar-policy.

I confirm that this PR (choose one, and delete the other options):

• Updates the "Unreleased" section of the CHANGELOG with a description of my change (required for major/minor version bumps).

I confirm that cedar-spec (choose one, and delete the other options):

• Does not require updates because my change does not impact the Cedar Dafny model or DRT infrastructure.

Disclaimer

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[cdisselkoen]

Two more comments:

1. This approach transforms only INT_MIN. Should we, more generally, represent (-X) as a negative integer literal instead of a negation operation of a positive integer literal, for all X?
2. It looks to me that only the CST->EST code was adjusted; is this sufficient? Is there AST->EST code that needs to be adjusted? I assume that EST->AST is OK

[aaronjeline]

1. This approach transforms only INT_MIN.  Should we, more generally, represent (-X) as a negative integer literal instead of a negation operation of a positive integer literal, for all X?

perhaps

2. It looks to me that only the CST->EST code was adjusted; is this sufficient?  Is there AST->EST code that needs to be adjusted?  I assume that EST->AST is OK

Yeah, all of those already have the integer literals as i64, whereas the CST has integers as u64s for the purpose of error messages

[aaronjeline]

Do we want to remove this code:

                match num_dashes {
                    0 => Ok(inner),
                    1 => Ok(Expr::neg(inner)),
                    2 => {
                        // not safe to collapse `--` to nothing
                        Ok(Expr::neg(Expr::neg(inner)))
                    }
                    n => {
                        if n % 2 == 0 {
                            // safe to collapse to `--` but not to nothing
                            Ok(Expr::neg(Expr::neg(inner)))
                        } else {
                            // safe to collapse to -
                            Ok(Expr::neg(inner))
                        }
                    }
                }

If the intent of the EST is to lossless preserve the policy?

[cdisselkoen]

Happy to approve as-is, possible followup per my comment above (transforming all negative literals and not just INT_MIN)