Emit N prefix for xml string literals in SQL Server

[Copilot]

String constants mapped to the SQL Server xml store type were generated without the N prefix, so they were treated as non-Unicode varchar. The database collation's codepage was then applied, silently corrupting characters outside it (e.g. emoji in XML attribute values).

-- before
SELECT COALESCE([m].[SomeXml], '<x Attr="😭" />') FROM [MyEntities] AS [m]
-- after
SELECT COALESCE([m].[SomeXml], N'<x Attr="😭" />') FROM [MyEntities] AS [m]

Changes

• SqlServerStringTypeMapping: extend the _isUtf16 detection to also recognize the xml store type. The xml mapping is created with unicode: true but a store type of "xml", which the existing StartsWith("n") guard excluded.
• Kept the StartsWith("n") guard (rather than reverting to plain parameters.Unicode) to preserve its original intent: a property mapped as Unicode but with an explicit non-Unicode store type (e.g. varchar) must not get an N prefix. xml is genuinely a Unicode store type, so it is added alongside n*.

_isUtf16 = parameters.Unicode
    && (parameters.StoreType.StartsWith("n", StringComparison.OrdinalIgnoreCase)
        || parameters.StoreType.StartsWith("xml", StringComparison.OrdinalIgnoreCase));

This also propagates to the related literal pieces (nchar(10/13) and CAST(... AS nvarchar(max)) inside CONCAT).

Tests

• Added GenerateProviderValueSqlLiteral_works_xml covering plain, escaped-apostrophe, emoji, and line-feed/CONCAT cases to confirm xml literals now emit N'...', nchar, and nvarchar(max).

[ErikEJ]

Equals("xml", StringComparison.OrdinalIgnoreCase)) ?

[AndriySvyryd]

Superseded by #38462