feat!: migrate Point<double> to Offset internally

[mootw]

This will yield significant performance benefits due to a reduction in casting. This likely breaks the external API but it is worth it

Migrations:
Point<double> -> Offset or Size
Bounds<double> -> Rect
Bounds<int> -> (rename and marked internal) IntegerBounds

maybe fixes #1769 (it is not a full migration, as there are still record types (they are okay in certain conditions honestly, especially as an interface between public apis), but it does fix a TON of issues with math.Point, which is much slower than the difference between Objects and Records)

there is a modest 7% performance boost in the polygon and polyline tests in both the UI and Raster threads in my debug mode profiling. i expect other layers to benefit and more performance boost in ideal situations

[JaffaKetchup]

Some things I would be even more heavy handed/breaking on. I would be in favour of implemented deprecated methods just to ease the transition for external users, but I think we need to be more thorough.

Is there any reason for keeping Bounds using Point?

[mootw]

Some things I would be even more heavy handed/breaking on. I would be in favour of implemented deprecated methods just to ease the transition for external users, but I think we need to be more thorough.

Is there any reason for keeping Bounds using Point?

Yes, I have only migrated the Point interface methods in Bounds because the DiscreteTileRange uses Bounds<int> which would mean that i need to implement a new IntegerBounds class on top of migrating Bounds or change DiscreteTileRange to no longer require integers

[JaffaKetchup]

Just a couple things left, mostly nits.

[JaffaKetchup]

LGTM 🎉. Performance seems to have improved (about 0.2ms on home page example app, 0.3-0.4ms on basic polygon page, untested others), enough to actually make things feel slightly smoother (but maybe that's just a placebo). Don't notice any bugs, and code looks good.

[josxha]

I like these changes. 😄
Maybe a feature release would be good before merging breaking changes?

Edit: I wouldn't be sad if we'd not use records here, but pr is fine as is too. (:

final (minx, miny) =
        transformation.transform(b.min.dx, b.min.dy, zoomScale);
    final (maxx, maxy) =
        transformation.transform(b.max.dx, b.max.dy, zoomScale);

[mootw]

i like that for future changes. I want to avoid creeping scope on this PR too much for now. we could wait to release for more changes

[JaffaKetchup]

Hi @hket-tommyluk,
Sorry if we've made a mistake! Can you please file a bug report if this is causing an issue and we'll look into it. I'm not clear what this would cause.