New 4.0 TileMap's API could be simpler.

[Mickeon]

Godot 4.0 presets itself with a whole reworked TileMap. However, the API may have lost some simplicity, clarity.

I may turn these into separate proposals, and may edit this list as I come up with more suggestions
For now, I believe:

• Switch the arguments around for get_cell_alternative_tile(), get_cell_atlas_coords() and get_cell_source_id().
  As of the time of writing this, it's "(int layer, Vector2i coords, bool use_proxies)".
  Layers are a new feature, and because of their grouping ability, it makes sense to have it needed to be specified first. However, they add another layer of complexity. It can also be assumed that beginning and returning users are not going to make use of it right away, since they were not present before, and basic TileMaps are just as functional with one layer. For these reasons, I believe the coords argument should come first (much like 3.x's get_cellv()).

• I also believe the layer argument should default to 0 whenever appropriate, whenever the method isn't explicitly about managing layers.

• • This could apply to get_used_cells().
• • set_cell() could use the same treatment, but due of the extra arguments, this may not be doable without making the method look like a mess.

• Re-implement the INVALID_CELL constant (-1). Plus, document when it could be returned.
  I don't see why it was omitted (at least from the documentation?). Could it be because it was too long, or because there's a constant that covers all "NOT_FOUND == -1" cases? Either way, it could be re-added under a different name, too (e.g. EMPTY_CELL).

• Its documentation could use some work, aiming towards simplicity and less technical speech (hello, proxies). Unlike a few of the above suggestions, it's not compatibility-breaking. It can be tweaked over time.

[groud]

I disagree on that. Unless we make the layer argument optional (which I don't really think we should, as I prefer explicit over implicit), I think we need to keep the hierarchy of importance in the order of arguments. I don't want to keep the previous state just to not confuse new or 3.x users.

Re-implement the INVALID_CELL constant (-1). Plus, document when it could be returned.
I don't see why it was omitted (at least from the documentation?). Could it be because it was too long, or because there's a constant that covers all "NOT_FOUND == -1" cases? Either way, it could be re-added under a different name, too (e.g. EMPTY_CELL).

Well, a single constant do not make a lot of sense, as you now have to retrieve three values as an ID assigned to a cell. Not sure they are exposed but we have TileSet::INVALID_SOURCE, TileSetSource::INVALID_ATLAS_COORDS and TileSetSource::INVALID_TILE_ALTERNATIVE. It might be worth exposing them I suppose.

Its documentation could use some work, aiming towards simplicity and less technical speech (hello, proxies). Unlike a few of the above suggestions, it's not compatibility-breaking. It can be tweaked over time.

Yeah, proxies are really difficult to explain, they were mostly implemented for compatibility purposes when you merge atlases together. But if anyone has better ways to formulate that, they are welcome.