Fix render-thread crash when a bound ItemsSource is mutated (SkiaLayout snapshot)

[LennoxP90]

Fixes #300.

Problem

ViewsAdapter stores the live, bound ItemsSource in _dataContexts and indexes it from the render
thread (GetOrCreateViewForIndexInternal). When a consumer mutates that collection on the UI thread
(Insert/RemoveAt — e.g. a windowed/virtualized list that pages data in and out during scroll), the
render thread tears a read of the resizing backing array → SIGSEGV in the runtime (100% Mono backtrace,
no GPU frames). Reproduces on Accelerated (GL thread) and Default (main thread).

Fix

Index an immutable snapshot of the items from the render thread instead of the live collection:

• _dataContexts becomes a property whose setter refreshes a volatile object[] _renderSnapshot.
• GetOrCreateViewForIndexInternal reads _renderSnapshot (atomic reference read; out-of-range simply
  yields no view that frame and self-heals).
• The snapshot is rebuilt on the UI thread on each data change — per change, not per rendered frame,
  so no per-frame allocations.

Single focused change in src/Shared/Draw/Layout/SkiaLayout.ViewsAdapter.cs. No features removed, no
public API added.

Testing

• Verified on Android (net10): the minimal repro (scroll-driven moving window — append at edge +
  RemoveAt(0)) crashes reliably on the stock package and no longer crashes with this change; built into
  and exercised via a MAUI app.
• The change is platform-agnostic C# (no TFM-/platform-specific code). I could not run the full
  iOS/MacCatalyst matrix on a Windows-only host — happy for CI / a Mac to confirm the rest.

Notes / for discussion

• Behavior: the render reads items as of the last change (the snapshot), refreshed on every
  CollectionChanged; please confirm this composes with the incremental-update paths
  (_HandleSmartCollectionChange etc.).
• The snapshot rebuild assumes collection mutation happens on the UI/dispatcher thread (the supported
  scenario); it guards defensively if not.

[taublast]

Hi @LennoxP90 thanks so much for this!

I found that the render thread also indexes the live collection in three more spots beyond GetOrCreateViewForIndexInternal:

• AttachView — _dataContexts[index] → view.BindingContext (the original crash site)
• DataContextIterator.MoveNext — _dataContexts[_currentIndex]
• GetChildrenCount — .Count (can mismatch the snapshot length → IndexOutOfRange)

So I created a derivative version of the fix, which snapshots all four read paths (each captures the snapshot ref once).
Crediting you as co-author on the commit #301 d4281b5 and will credit in the upcoming bulk PR very soon, please let me assemble everything, I see you have another PR incoming, I haven't checked it yet :)
Will close this in favor of the above commit when the final PR is merged. Thanks again for the clean repro and the correct fix direction!

I will look into the repro you provided to make this use-case work well, and make needed changes to the lib to handle this optional use-case. As i see it, it's something like a "two-directional LoadMore with optional removal of already loaded data". This is a nice use-case that could totally be handled internally to minimize the number of remeasurings and boilerplate coding. And by the way, the Scrolled event is not fired on the UI thread.