iOS: Recomposite platform views only if their parameters change - #196287

FlutterPlatformViewsController tracks a set of views to recomposite
such that we only call compositeView:withParams: for views whose
composition parameters changed since the previous frame. It turns out
that it didn't actually do that:

• We only ever cleared the set in reset. Once a view's parameters had
  changed once, we recomposited it on every subsequent frame until hot
  restart. This has been the case since the set was introduced in
  Move the mutators stack handling to preroll flutter-team-archive/engine#9651.
• We compared at preroll, but the visited-platform-view callbacks
  (pushFilterToVisitedPlatformViews: and the clip equivalents) append
  mutators to the stored parameters afterwards. The next frame's
  incoming parameters never matched the stored copy, so we
  recomposited any view beneath a backdrop filter on every frame
  regardless, allocating a fresh UIVisualEffectView each time.

This moves the parameter comparison to submitFrame:, after the
callbacks have run, and compares each view's final parameters against
the ones we submitted in the previous frame. currentCompositionParams
is now per-frame state that we clear at the same time as the composition
order.

Views with no previous entry are always composited. That covers views
recreated under a disposed ID since onCreate: doesn't insert an entry
for any view ID that is still registered. We only unregister an ID when
we present a frame that no longer includes it.

computeViewsToDispose runs on the platform thread but was reading the
composition order from (and erased entries in) state managed by the
raster-thread. It now takes the composition order and no longer touches
any raster-side maps.

compositeView:withParams: is idempotent, so nothing changes in terms
of the pixels. We just call it less often.

Also added new tests to cover the unchanged, changed, filtered, and
recreated cases.

Issue: #112232

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.