Expose TDLib object vectors as List<T>

[FrayxRulez]

Generated TDLib objects expose their vectors as List<T> instead of IList<T>. Functions are
left alone.

Why

A XAML binding assigns through the declared type, so with IList<T> the concrete type only exists
at runtime and nothing can see it at compile time. That is how SettingsStoragePage came to bind
Statistics.ByChat to ItemsSource and fail with E_INVALIDARG, with no warning anywhere. With
List<T> the type is visible in the generated binding code, and the analyzer reports it.

Two more reasons, both on paths that run per render:

• foreach over an IList<T> boxes the enumerator. List<T> has a struct one. .Entities alone is
  iterated in 23 places.
• The indexer and Count inline instead of dispatching through the interface.

Functions gain none of this - they are only ever written and serialised, never bound or iterated -
and keeping IList<T> there leaves 93 call sites able to pass an array. So they keep it.

Shape

• Object properties and constructor parameters are List<T>; nested vectors are List<List<T>>.
• Both parsers already materialised a vector as a List<T>, so nothing changes at runtime for a
  parsed response. The nested readers now build List<List<T>> and the WriteArray overload for
  them was widened to match.
• Call sites moved from new[] { x } and Array.Empty<T>() to [x] and [], which allocates
  less than the intermediate step did - the converter copied every array into a list.

Worth a look in review

• TryGetColors and the two chat-list readers fill by Add rather than by index. A List's
  capacity is not its count, so the literal translation of new T[n] would throw.
• TextStyleRun.NoEntities and AnimatedImageSource.NoOutline are shared empty lists, because
  Array.Empty<T>() was free and these sit on the render path. A shared mutable list is a
  footgun: IList<T>.Add on an array used to throw, and now it silently corrupts a singleton.
  Inheriting a frozen List<T> cannot help - the members are not virtual, so the guard is inert
  whenever the static type is List<T>, which it always is here. The plan is to return a fresh list
  from GetEntities, whose result callers may edit, and to add a debug-only check that the count is
  still zero.
• MessageServiceText.ReplaceWithLink loses an if (Entities.IsReadOnly) copy-guard that only
  existed because an IList<T> could be a read-only array wrapper.
• Three foreach (… in x.Reverse()) became index loops: List<T>.Reverse() is in-place and returns
  void, so they no longer compile as written. The one bare x.Reverse(); statement in the codebase
  is on a different type and is unaffected.

Builds clean. Not run.

Note on the diff

This stacks on three commits that are on develop locally but not yet pushed, so the PR currently
shows six. The first three drop out once develop is pushed.