Consistency pass over error messages

[khieta]

Description of changes

Another pass at standardizing error messages. My changes are meant to align with the following rules (loosely inspired by https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-structure):

• Error messages should avoid capitalization and periods. If multiple sentences are needed then use grammatical capitalization and punctuation only on the message’s interior. Example: wrong number of arguments in extension function application. Expected {}, got {} (note the initial lowercase letter and lack of final period).
• Error messages should not include line breaks.
• User-provided input (e.g. attributes, entity uids, policy ids) should be surrounded with backticks or otherwise clearly separated from the rest of the message. Use of backticks is preferred. Examples: undeclared action `foo` , undeclared entity type(s): {"Foo"}
• Related error messages should be concatenated with colons. Example: error occurred while evaluating policy `policy0`: `User::\"alive\"` does not have the attribute `foo`
• Error messages should not use contractions (e.g., “don’t”). (This last one isn't as important as the others -- just my mood today.)

Issue #, if available

Checklist for requesting a review

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

• A change "invisible" to users (e.g., documentation, changes to "internal" crates like cedar-policy-core, cedar-validator, etc.)

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.

[shaobo-he-aws]

LGTM.

[max2me]

minor suggestions/nitpicks

[max2me]

Should the {expected} and {actual} types be surrounded with backticks?

[khieta]

I haven't been surrounding types with backticks -- see my comment below.

[max2me]

should types be surrounded with backticks?

[khieta]

I decided not to surround types with backticks since they are not verbatim user input, and I felt that expected bool but saw string was just as clear as expected `bool` but saw `string` . Open to second opinions.

Note: Your comment made me realize that we weren't following the rules when printing types (we were printing entity of type Foo rather than entity of type `Foo` ). Fixing this required changing a bunch of the corpus tests, which is why the diff in my recent commit is so large.

[khieta]

For reference, here is how we currently print types:

• bool
• long
• string
• set
• record
• (entity of unspecified type)
• (entity of type `Foo`) where Foo is some user-specified name