[this is a rethread of https://github.com//pull/181110]

addressing the comments:

• data driven fix - I looked into this, but unfortunately I don't think it fits - it seems to key off of method name changes; signature-only changes do not appear to be supported. As I mentioned this is a trivial change in the guts of scrollbars, so while technically breaking change (if someone is extending it directly), end users probably wouldn't notice this, and anyone creating their own custom scrollbars have a clear path forward.
• keeping both versions of the methods: I also considered this but that unfortunately doesn't help with the ultimate buttons goal, because anyone calling the old signature just doesn't give enough information to fully reconstruct the event. the reason for this change is to force callers to provide the entire event thus guaranteeing we have the info needed to propagate button (and better future proofing against any other such changes).
• copyWith and nullability - agreeing with the confusing semantics of copyWith exposed by @Renzo-Olivares , so I just removed it. this makes this PR much simpler, and the final state still a bit "brittle", in the sense that future event additions need to be aware of updating the ad-hoc copies, but it is still a much nicer state than before, and fully unblocks my ultimate goal of exposing buttons, so I am happy with it.

[original description]

This PR changes the signatures of handleThumbPressStart, handleThumbPressUpdate, and handleThumbPressEnd, related to scrollbar handling, to take in a copy of the original event with the localPosition added inside, instead of separate fields.

This centralizes the copying of these events by the generic platform code (while still allowing some of them to re-copy based on implementation details), ensures that additional fields are propagated (such as kind when it exists, buttons when it is eventually added, and others) and simplifies the method signature significantly, future proofing it to future additions.

This was extracted from #176968 in an attempt to simplify it, and it will make it possible to add the missing buttons property to these events more easily.

Note: this is a public signature change but only if people are creating their own custom scrollbar implementations (?) without using either the material or cupertino ones; and on top of that should be very trivial to fix. But please advise if there are concerns.

Note: this has no test changes because it is a refactor which should have zero change in behaviour; the existing tests passing is proof of it working.

Note: this PR assumes that the renderBox.localToGlobal(localPosition) computation that was previously done was essentially the reverse of the global -> local computation, so essentially the flow was global --(global to local)--> local --(local to global)--> global (the second step being there just because we didn't provide the original global to the method). So this is saving a computation step and should not change the behaviour. I will let the tests be the judge of this assumption but please let me know if there are concerns.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• 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 documentation (doc comments with ///).
• 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.