feat: Configure custom ID when adding objects such as markers.

[fummicc1]

• [Feature request]: Marker IDs are forcibly overwritten regardless of user-specified IDs #288

To address above issue, I add new API for adding markers / polylines / polygons / circles.

This change does not break existing behavior if I understand correctly.

Motivation of this PR is same as #288 . Currently I have no idea to classify what marker is clicked.
Though I can obtain information of markerId from onMarkerClicked but it is managed by internal API.
In adding Marker, the information I can customize is MarkerOptions, so it is hard for marker object to affiliate with domain model.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation
• I added new tests to check the change I am making
• All existing and new tests are passing.

[jokerttu]

@fummicc1
Thanks for your contribution!

Note that there is a separate method for updating existing markers, which preserves the generated IDs:
#288 (comment)

The reason we don't allow developers to set IDs manually is to avoid collisions, as having the same ID on multiple markers causes issues in the platform implementation.

When a marker is added, the platform returns the added markers in the same order with generated IDs.
If developers need custom IDs, they currently have to handle mapping between IDs in their own implementation. This means they need to maintain a separate mapping between their custom IDs and the generated platform IDs, ensuring that interactions such as marker clicks or updates can be correctly linked back to their original identifiers. I admit this is not the easiest approach, as it requires additional logic to track and synchronize these mappings manually.

We will discuss internally whether we should provide the possibility to customize marker IDs (or other object IDs), with a clear warning about potential collisions.

The approach you suggested would work, but if support for custom IDs is added, we could consider making it an optional setting in the Options object or introducing a breaking change to modify this behavior, as this package is still in beta.

No need to update the PR just yet, as this is under discussion.
Continue discussion on the issue at: #288 (comment)