Add mapgl layer visibility provider support

[e-kotov]

This PR connects {deckglgeoarrow} to {mapgl}’s layer visibility provider API, so GeoArrow layers can be turned on and off from mapgl’s layer selector. This depends on {mapgl}PR #225 being merged (cc @walkerke).

---

There is a separate issue in {deckglgeoarrow}: when two GeoArrow layers use the same source=, they share one selector entry and turn on or off together. That may be surprising if someone wants to control those layers separately. Fixing it would mean changing how {deckglgeoarrow} assigns IDs to its layers and sources.

@tim-salabim I’ve kept that separate from this PR. Would it be useful for me to prepare a follow-up PR so layers that share a source can still be toggled independently?

[tim-salabim]

@e-kotov can you elaborate a bit more on why this is needed? With the helper function generateDeckglLayerId() the layer toggling already works as expected doesn't it?

Regarding the issue that it does not work when the layer share the same source, that's a good catch! No need for a PR, that should be an easy fix to be done on my side.

[e-kotov]

@tim-salabim With the current CRAN versions, listing a GeoArrow layer’s layer_id directly in add_layers_control() does not toggle it. Users have to provide its generated Deck.gl ID, which adds more code and seems unnecessary, as better package integration can be achieved:

# Current CRAN versions
add_layers_control(layers = list(
  "Test area" = generateDeckglLayerId("test-area")
))

With the changes in the {mapgl} and {deckglgeoarrow} PRs, they could list the layer’s layer_id directly:

# With both PRs
add_layers_control(layers = list(
  "Test area" = "test-area"
))

So far, this does not mean that the add_layers_control will be able to auto list all deckglgeoarrow layers if no args are specified (like it does now with its own layers). For that, I would probably need to submit more changes to {mapgl}.

[tim-salabim]

@e-kotov I just pushed a fix which separates layer_id from an internally used sourceId which will only be used to read the data. This should be safer as potential mix-ups are avoided. However, I think this also means that this PR here needs updating.

In general, regarding this PR, I am a bit hesitant on the proposed changes here, as it means diversion from the core behaviour of how Deck.gl integrates with maplibre.gl... For a low-level package like this one, I am mostly fine with some more code effort required in the API.

But I am still open to be convinced otherwise :-)

[e-kotov]

For a low-level package like this one, I am mostly fine with some more code effort required in the API.

But why do you consider it low level? In my mind this is a direct extension of 'mapgl' and I (putting myself in lay-user's shoes) would expect it to work very similar to 'mapgl''s own layers (which, btw, includes the style of arguments in the layers).

I will have a look what you changed and what needs to be changed in this PR.

[e-kotov]

Update: after your changes in main this PR does not need any updates.