perf!: remove unnecessary rounding and surrounding features, and produce less garbage

[ignatz]

Sorry, this combines a bunch of things that could be pulled apart. This is the result of me going on a spree trying to speed up Polygons, which are still the slowest experience in my App.

In a nutshell:

1. Cleaned up some internals in CRS. Addressed a couple potential sources for exceptions why may have been the reason for the whole try/catch. Arguably the recovery in the catch doesn't make much sense.
2. Then I noticed that pixelOrigin is rounding, which is plain wrong because Flutter operates on virtual pixels which can be fractional. So this rounding can introduce visual artifacts at no benefits.
3. Then I noticed that there's an entire family of Point extensions just to cover up the erroneous rounding. So I removed those (mostly). Also scaleBy is not a vector scaling operation. I don't know what it is or what it would ever be used for. So I removed it as well.
4. Finally, actually speed up polylines and polygons by doing less work, producing less garbage, and culling labels for polygons.

This is were @JaffaKetchup is hopefully going to say: "(2) and (3) break public APIs" :)

I'd argue that (2) is a bug that needs fixing. Whereas (3) is negotiable. Note that I left the Point<double>.subtract method, which I presume is the only one ever used to deal with (2). I definitely don't think we're setting a good example by helping dig a hole into type-safety :).

[JaffaKetchup]

(2) and (3) break public APIs 😂.

I won't give my full thoughts or review now, as I'm on a phone with 8% battery, but I'll look at it this evening. However...
We're really greatful for these improvements to polygons, as we're looking to do that privately as well. In fact, there's some internal discussion going on, and let's just say that there might be some bounties available at some point soon from an external company. Can't explain it publicly just yet, nothing is certain, but it's certainly looking like it's going to happen. Maybe you should join the Discord server if you're not already there, and ping me. I can then keep you in the loop a little more, assuming the external company is ok with that.

[ibrierley]

I'd be very wary about not rounding pixelOrigin without a good reason. Leaflet.js has done this forever iirc, and flutter_map has done this pretty much forever, and floats often lead to odd bugs (not specifically meaning flutter_map here). Here is one example in leaflet for the reasoning https://stackoverflow.com/questions/60412852/is-there-any-reason-why-leaflet-rounds-pixel-coordinates (I'm not sure if flutter->web would have this issue or not). I also suspect odd errors from things like this when I see narrow white lines between tiles (I note google maps suffers from this now and it bugs me :) )

There are some potential advantages I think like that issue says about animations potentially.

Just be careful with it, without a lot of testing and thought as to how others use calculations based on the concept that its currently rounded.

[ignatz]

@ibrierley testing sounds good. FWIW, it's a bit more tricky especially when it comes to what FlutterMap has done forever. I'm removing the rounding from pixelOrigin specifically, however most pixel coordinates are computed as (map.project(latlng) - pixelOrigin), i.e. you end up with floating point numbers one way or another, just with more or less error.
How big that error is right now also ends up depending on what your device's devicePixelRatio is. When it comes to aliasing issues, in the end you gotta trust flutter with it since flutter only let's you handle logical pixels and even the ratio between physical and logical pixels can be rational.

I certainly agree, let's all be diligent.

[JaffaKetchup]

@ignatz is this ready for review?

[JaffaKetchup]

LGTM, although this is breaking, it's very minor (num to double for only a small number of users). Thanks!

Not fully reviewed

[JaffaKetchup]

I think everything is OK in terms of rounding changes @ibrierley.
I think I'm OK with the breaking changes here as well. LGTM, thanks!