Escape Unicode line separators in CSharpHelper string and char literals

[ilkertskn]

• Escape U+2028 (LINE SEPARATOR), U+2029 (PARAGRAPH SEPARATOR) and U+0085 (NEXT LINE) using their backslash-u escape sequences in Literal(string) and Literal(char)
• The C# compiler treats these code points as new-line characters, so emitting them raw produced generated code that failed to compile (CS1010: Newline in constant)
• Add tests covering the three separators for both string and char literals

• I've read the guidelines for contributing and seen the walkthrough
• I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
• The code builds and tests pass locally (also verified by our automated build checks)
• Commit messages follow this format:

        Summary of the changes
        - Detail 1
        - Detail 2

        Fixes #bugnumber

• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

[ilkertskn]

@dotnet-policy-service agree

[Copilot]

Pull request overview

This PR fixes a code-generation edge case in CSharpHelper where certain Unicode newline code points (U+2028 LINE SEPARATOR, U+2029 PARAGRAPH SEPARATOR, U+0085 NEXT LINE) could be emitted unescaped inside string/char literals, causing generated C# to fail compilation (e.g. CS1010 “Newline in constant”).

Changes:

• Escape U+2028, U+2029, and U+0085 via \uXXXX sequences when emitting C# string literals in CSharpHelper.Literal(string).
• Escape the same code points when emitting C# char literals in CSharpHelper.Literal(char).
• Add design-time tests covering these characters for both string and char literal emission.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/EFCore.Design/Design/Internal/CSharpHelper.cs	Adds escaping for Unicode newline code points in string and char literal generation.
test/EFCore.Design.Tests/Design/Internal/CSharpHelperTest.cs	Adds regression tests asserting the escaped \uXXXX output for string and char literals.

Comments suppressed due to low confidence (2)

src/EFCore.Design/Design/Internal/CSharpHelper.cs:410

• In Literal(char), consider using character literals ('\u2028', etc.) in the switch patterns for clarity instead of numeric casts.

                (char)0x2028 => "\\u2028",
                (char)0x2029 => "\\u2029",
                (char)0x0085 => "\\u0085",

test/EFCore.Design.Tests/Design/Internal/CSharpHelperTest.cs:92

• Test name says "line and paragraph separators" but the test also covers U+0085 (NEXT LINE). Rename to reflect that these are all Unicode newline characters.

    public void Literal_escapes_unicode_line_and_paragraph_separators_in_char()