Implement a faster version of FromNormalizedStr for Names

[jv-garcia]

Description of changes

In #1411 we discussed an approach to significantly improve performance of this code, which happens to be consuming quite a lot of CPU time in our team's use of Cedar. This is a more formal attempt to implement it. I've had this stashed locally for a while, but I won't be able to work on this for a few weeks, so I wanted to get the PR out and at least get some discussions started on whether this is a good idea and what might be missing if it is.

Performance does seem to be significantly better given benchmarking results, examples:

Benchmarking EntityTypeName parsing/Type Name size 23: Collecting 100 samples in estimated 5.0007 s (14M iEntityTypeName parsing/Type Name size 23
                        time:   [361.68 ns 362.18 ns 362.68 ns]
                        change: [-94.906% -94.889% -94.872%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  3 (3.00%) high mild
Benchmarking EntityTypeName parsing/Type Name size 63: Collecting 100 samples in estimated 5.0016 s (7.0M EntityTypeName parsing/Type Name size 63
                        time:   [709.22 ns 711.58 ns 714.34 ns]
                        change: [-93.066% -93.021% -92.977%] (p = 0.00 < 0.05)
                        Performance has improved.

This of course comes at the cost of having to maintain this somewhat duplicated specific parser for these bits. Given the performance gains, the benefit seems worth to me, but well, this is something that should be discussed for its long-term maintainability.

I also haven't researched if there are better ways to accomplish better performance with the current framework, so there might be some opportunities there.

Issue #, if available

#1411

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.)