Project with rotation to avoid MobileLayerTransformer

[Robbendebiene]

I really like the merge of the children properties into one done by #1615

However the MobileLayerTransformer feels incorrectly documented as it only rotates the layer, while the docs says:

can move and rotate based on the [MapCamera]

I was confused, that at first all my custom layers seemed to work correctly without it, until I started rotating the map.

That got me thinking, wouldn't it be possible to include the rotation in the projection? Or at least another function that returns the projected points correctly rotated? This way no MobileLayerTransformer is needed when writing most custom layers.

At least I slightly suffered from this as I implemented some of my layers as RenderObjectWidgets where I wasn't able to simply throw in the MobileLayerTransformer.
More importantly though this could improve the marker layer as it removes the need of counter rotating map markers.
Also when the map rotates markers usually have to be re-evaluated anyway (check if marker lies inside the visible bounds/view or not).
I think layers like polygon, circle and line layer should likewise benefit from it.

Other layers like the tile layer could still use a Transform widget themselves.

Working code to project and rotate:

final pxPoint = mapCamera.project(point);
final relativePixelCenter = mapCamera.nonRotatedSize / 2;
final unrotatedPixelOrigin = mapCamera.project(mapCamera.center) - relativePixelCenter; // btw mapCamera.pixelOrigin doesn't seem to do what it pretends to do from the docs since it uses the rotated rect/size for its calculation
final relativePos = pxPoint - unrotatedPixelOrigin;
final pos = mapCamera.rotatePoint(relativePixelCenter, relativePos, counterRotation: false);

This has probably been discussed at some point. I'm curious what your thoughts are.

[JaffaKetchup]

In regards to the documentation, it's worded that way on purpose.
Although it's technically true that it doesn't allow the layer to move - they're allowed to move by default, and something like SizedBox or Align is needed to expand the widget and prevent movement - it shouldn't be used if movement isn't wanted, and it should always be used (or at least a technical equivalent) when movement is wanted, IYSWIM.
We decided to allow all widgets directly in the children list, instead of specifically allowing only a recommended subset, because then that allows usage of things like StreamBuilder around standard layers. This does however, mean you can end up in the situation you found, with an unforeseen bug.

In regards to just including rotation along with the default projections, I'm not really an expert around that stuff :D. I believe it may have come up before, but there were possibly some issues or something. Open to changing this again, just not too quickly after v6! But best to leave me out of the technical conversation around projections.

[Robbendebiene]

Thanks for the explanation. Makes sense from this point of view. Perhaps some of your writings could be added to the dart doc :)

Regarding the projection changes, perhaps this could be introduced without breaking anything by adding another method like projectWithRotation or projectRotated. Developers then have the choice between this method or a combination of projection and MobileLayerTransformer.

Anyway I would like to gather some other thoughts before making any PR.