fix: ProjectionDataParams no longer requires OverscaledTileID instance

[kubapelc]

transform.getProjectionData() is part of the public API that is useful when rendering completely custom tiles, but the ProjectionDataParams object it accepts as parameter requires an instance of OverscaledTileID, which is only exported as a type by MapLibre. This makes it cumbersome to use, since there is no easy way of creating an OverscaledTileID instance.

This PR modifies the ProjectionDataParams object to also accepts an object literal, in addition to an OverscaledTileID instance, making it easy to use by external code. getProjectionData implementations are also modified to accept this object literal.

There doesn't seem to be a preexisting issue for this, and it was a simple fix, so I went ahead and implemented it.

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Document any changes to public APIs.
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[HarelM]

Transform is not really a part of the public API.
Can you elaborate on what you would like to achieve and maybe expose something else?

[kubapelc]

Hi! My original intention when implementing globe was for getProjectionData to be available to users. The reason is that this function is essential for making complex custom layers that work both on mercator and globe and also work seamlessly with the rest of MapLibre. There is even an example on how it can be used to make such a layer:

https://maplibre.org/maplibre-gl-js/docs/examples/add-a-custom-layer-with-tiles-to-a-globe/

Scope of this PR is only to fix the function's parameter types to make sure it can be used properly without creating OverscaledTileID instances. I think OverscaledTileID class was fully exported back when globe was implemented, but since has changed to only be exported as a type.

[HarelM]

I don't think it was ever exposed as is, but that's besides the point.
Custom layer has an interface that we can add data to if needed, like the matrices.
If you need this as a public API you need to expose it from the map object.
But if it can only really be used in a custom layer I think it will be better to expose it there only.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.77%. Comparing base (0b9b3bd) to head (3285b7f).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7471   +/-   ##
=======================================
  Coverage   92.77%   92.77%           
=======================================
  Files         289      289           
  Lines       24021    24030    +9     
  Branches     5100     5105    +5     
=======================================
+ Hits        22286    22295    +9     
  Misses       1735     1735           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kubapelc]

Okay, I see no harm in exposing getProjectionData properly, though my intention was only to fix a minor bug. I've added it to custom layer args in the latest commit, and tweaked the example I linked earlier to use it. The function is only useful for custom layers, and is only needed during rendering of tiles, so I think that custom layer args is a better fit than expanding the map's API. Let me know what you think!