Perf: Reduce allocations across 5 controls with targeted optimizations

[PaulAndersonS]

Root Cause of the Issue

Multiple controls allocate unnecessary collections (List, Array) in frequently-called methods, causing GC pressure and reducing throughput during layout, rendering, and user interaction.

Description of Change

Five targeted performance improvements that reduce heap allocations:

1. OtpInput (SfOtpInput.cs) — Replaced O(n²) Concat(new[]{x}).ToArray() pattern in AddEntry, SetInputFieldPosition, and SetSeparatorPosition with a List<T>-based approach that builds the collection once and converts to array at the end.

2. Carousel iOS (PlatformCarousel.iOS.cs) — Replaced .ToList().ForEach(...) with a direct foreach loop, eliminating a List allocation. Also cached the IsInteractionEnable() result to avoid calling it N+1 times.

3. SfView (SfView.cs) — Removed the redundant .AsReadOnly() wrapper in GetVisualChildren(), which allocated an extra ReadOnlyCollection<T> on every call. List<T> already implements IReadOnlyList<T>.

4. DatePicker (SfDatePicker.cs, DatePickerHelper.cs) — Replaced MonthNames.ToList().IndexOf(...) with Array.IndexOf(MonthNames, ...), eliminating 4 separate List allocations per month-selection event.

5. ProgressBar (SfLinearProgressBar.cs, SfCircularProgressBar.cs) — Replaced LINQ OrderBy(...).ToList() with new List<T>(source) + List.Sort() for in-place sorting of gradient stops, eliminating the intermediate iterator and sort buffer allocations.

Issues Fixed

N/A — proactive performance improvement

Unit Tests Added

• DatePickerMonthIndexUnitTests — Verifies Array.IndexOf produces identical results to the previous List.IndexOf approach for all month name formats
• LinearProgressBarGradientSortUnitTests — Verifies gradient stops are correctly handled after the sort optimization (out-of-order, single-stop, already-sorted scenarios)

[MuniappanSubramanian]

Date Picker code changes are fine