Refactor: Add explicit StringComparison to string comparison methods

[JoonghyunCho]

Summary

This PR adds explicit StringComparison.Ordinal arguments to string comparison methods that were previously using the default culture-sensitive behavior. The changes span 14 files across Tizen.NUI and Tizen.Pims.Calendar.

Background

Several .NET string methods use CurrentCulture when no StringComparison is specified:

Method	Default (no arg)
String.Compare(a, b)	CurrentCulture ⚠️
.StartsWith(string)	CurrentCulture ⚠️
.EndsWith(string)	CurrentCulture ⚠️
.IndexOf(string)	CurrentCulture ⚠️
.Equals(string)	Ordinal ✅
.Contains(string)	Ordinal (.NET 5+) ✅

Since TizenFX runs on global devices (including Turkish, Arabic, German locales), relying on CurrentCulture for internal symbol/protocol/format string comparisons can cause subtle, hard-to-reproduce bugs — most famously the "Turkish I problem" where case-insensitive culture comparisons yield unexpected results.

This is also flagged by FxCop rules CA1307 and CA1309.

Changes

Tizen.Pims.Calendar — 5 changes

CalendarDatabase.cs

• String.Compare(CalendarViews.*.Uri, record.Uri) == 0 → .Equals(record.Uri, StringComparison.Ordinal)
• URI strings such as "tizen.calendar/book" are internal ASCII constants; String.Compare without StringComparison defaults to CurrentCulture.

Tizen.NUI — 35 changes

BaseComponents/ImageView.cs (6 changes)

• StartsWith("*Resource*") → StartsWith("*Resource*", StringComparison.Ordinal) — resource URL marker
• StartsWith("dali://") / StartsWith("enbuf://") → Ordinal — internal DALi protocol prefixes

ViewProperty/ImageShadow.cs (1 change)

• StartsWith("*Resource*") → Ordinal

BaseComponents/ViewBindableProperty.cs (1 change)

• StartsWith("*Resource*") → Ordinal

Visuals/VisualObject/ImageVisual.cs (2 changes)

• StartsWith("dali://") / StartsWith("enbuf://") → Ordinal

Common/Color.cs (2 changes)

• StartsWith("RGBA(") / StartsWith("RGB(") → Ordinal — color format string parsing

internal/XamlBinding/TizenPlatformServices.cs (1 change)

• StartsWith("System.") / StartsWith("Microsoft.") / StartsWith("mscorlib") → Ordinal — assembly name filtering

public/Utility/SpTypeConverter.cs (1 change)
public/Utility/DpTypeConverter.cs (2 changes)
public/Utility/SdpTypeConverter.cs (1 change)
public/Utility/PointTypeConverter.cs (6 changes)
public/Utility/GraphicsTypeManager.cs (6 changes)

• Unit suffix matching: EndsWith("sp"), EndsWith("dp"), EndsWith("px"), EndsWith("sdp"), EndsWith("pt"), EndsWith("spx") → Ordinal

public/BaseComponents/TextLabel.cs (4 changes)

• Equals("BEGIN") / Equals("CENTER") / Equals("TOP") → Ordinal
• Note: string.Equals(string) is already Ordinal in .NET 5+; these changes are for explicitness and consistency.

internal/XamlBinding/BindingExpression.cs (2 changes)

• EndsWith("IElementController.SetValueFromRenderer") → Ordinal — method name matching
• EndsWith(".") → Ordinal — decimal input validation

Risk Assessment

All 41 changes carry no practical risk:

• Every affected string is a pure ASCII literal (protocol prefixes, unit suffixes, internal symbol names, format tokens).
• CurrentCulture and Ordinal produce identical results for pure ASCII strings in all locales.
• The Equals() changes in TextLabel.cs are behaviorally a no-op (instance Equals was already Ordinal in .NET 5+).
• No public API signatures are affected — all changes are within internal/private implementation code.

Scope

• Public API contract: Unchanged
• Runtime behavior: Identical across all locales
• Build: No new dependencies; StringComparison is part of System namespace