Adds JSON serialized PolicySet from bindings to cedar_policy::PolicySet conversion

[muditchaudhary]

Description of changes

• Adds function to convert JSON serialized PolicySet object from bindings (E.g., CedarJava) to a cedar_policy::PolicySet instance
• The resulting instance can be used to expose cedar_policy::PolicySet's methods (E.g., to_json) in bindings

Issue #, if available

Checklist for requesting a review

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

• A breaking change requiring a major version bump to cedar-policy (e.g., changes to the signature of an existing API).
• A backwards-compatible change requiring a minor version bump to cedar-policy (e.g., addition of a new API).
• A bug fix or other functionality change requiring a patch to cedar-policy.
• A change "invisible" to users (e.g., documentation, changes to "internal" crates like cedar-policy-core, cedar-validator, etc.)
• A change (breaking or otherwise) that only impacts unreleased or experimental code.

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).
• Does not update the CHANGELOG because my change does not significantly impact released code.

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

• Does not require updates because my change does not impact the Cedar formal model or DRT infrastructure.
• Requires updates, and I have made / will make these updates myself. (Please include in your description a timeline or link to the relevant PR in cedar-spec, and how you have tested that your updates are correct.)
• Requires updates, but I do not plan to make them in the near future. (Make sure that your changes are hidden behind a feature flag to mark them as experimental.)
• I'm not sure how my change impacts cedar-spec. (Post your PR anyways, and we'll discuss in the comments.)

I confirm that docs.cedarpolicy.com (choose one, and delete the other options):

• Does not require updates because my change does not impact the Cedar language specification.
• Requires updates, and I have made / will make these updates myself. (Please include in your description a timeline or link to the relevant PR in cedar-docs. PRs should be targeted at a staging-X.Y branch, not main.)
• I'm not sure how my change impacts the documentation. (Post your PR anyways, and we'll discuss in the comments.)

[cdisselkoen]

Could you say a little bit more about why this function is required? As opposed to just using serde to deserialize the string into a struct that includes PolicySet as a field, and then using .parse() on that PolicySet

[cdisselkoen]

Returning Box<dyn Error> instead of DetailedError or something that impls miette::Diagnostic diverges from what a lot of the rest of the FFI functions do, and loses structured error information. Is there a reason this API should have less structured error information (e.g., no help text, no source location) than other APIs?

[muditchaudhary]

Will change this to match other FFI functions

[muditchaudhary]

Could you say a little bit more about why this function is required? As opposed to just using serde to deserialize the string into a struct that includes PolicySet as a field, and then using .parse() on that PolicySet

.parse for PolicySet has visibility pub (super) so it is not visible to CedarJavaFFI. If changing its visibility to public is acceptable, I can use that instead.

[cdisselkoen]

I think changing the visibility is preferable to introducing a new function in this case.

[cdisselkoen]

Elsewhere (e.g., in ffi/is_authorized.rs), function names with just json take a serde_json::Value, while functions like this that take a string have names with json_str