Expose GridMapEditorPlugin to scripts and add methods to manipulate to the selection and selected palette item

[badsectoracula]

This PR allows editor scripts and plugins to access GridMapEditorPlugin and adds methods for extending the editor's functionality by allowing manipulation of the selection and selected palette item.

This addresses and closes godotengine/godot-proposals#11161. It can also help with custom grid map tools that could be added later by scripts as i wrote in godotengine/godot-proposals#11206 (comment).

The video below shows how it could be used to implement a script that replaces tiles in the selection:

Godot.Gridmap.Selection.Plugin.webm

(obviously this is just an example -and probably the replace functionality should be core part of the editor- to show how the API can be used but it could also be used for making game-specific tools like assigning data -to be stored elsewhere, like in a node- to cells, or to pre-fill a gridmap with some procedural code that can be then manually edited, or to quickly set data and/or colors -especially useful for data as they can be something different than color- if #94282 is merged, etc)

EDIT:

Attached MRP with the script in the screenshot (though different map). To test it open the "node_3d.tscn" scene, select the "Floor" gridmap, pick "Floor3" from the available tiles (the cracked one), activate the "Replace Tile" dock (should be at bottom left), click the "Pick original tile" button (the label should change to "Select an item to replace 4 with"), make a rectangular selection in the viewport with some cracked tiles inside, pick "Floor2" from the available tiles (the one with the dark smudge) and click the "Replace in selection" button (note: if some tiles at the selection edges do not change that is because the tiles have their origin at the corner and thus the selection can be misleading a bit - that is an issue with the assets, not this PR).

The MRP:
gridmap-editor-scripting-test.zip

[Mickeon]

Surface-level look at the docs

[badsectoracula]

Latest PR fixed CI and made the modifications to the docs and API @Mickeon suggested and fixed the issues stemmed from multiple instantiations of the GridMapEditorPlugin class during its registration that i didn't notice. Instead of doing it the constructor, the UI control is now created when the plugin is attached to the tree (and destroyed when it is detached), which i think is a better place to create it anyway.

[Calinou]

@badsectoracula Can you upload the script you used for testing somewhere (or ideally a full MRP)? This will make it easier to review the PR and document its functionality 🙂

[badsectoracula]

@Calinou i made and attached an MRP. It is the same script though i used some different assets i made myself.

[hpvb]

Given that the doc changes were approved, the code changes look obviously correct to me and desirable. Lets gooooo.

[tetrapod00]

Approving for docs only

[Calinou]

Tested locally, it works as expected. Code looks good to me.

Note that this is the first time we expose a SomethingEditorPlugin to the scripting API:

Given this is too specific to expose within EditorInterface (and it's part of a module), I can't think of a better solution to this. @KoBeWi @Zylann What do you think?

[badsectoracula]

Given this is too specific to expose within EditorInterface (and it's part of a module), I can't think of a better solution to this. @KoBeWi @Zylann What do you think?

You mean the way the instance is accessed (by obtaining a node via the editor interface and then looking for the plugin node)? While perhaps a cleaner convenience API could probably be exposed via EditorInterface, since all plugins seem to end up (AFAICT anyway) as nodes, if nothing else it can be a useful way to demonstrate how they could communicate with each other (which was a concern i had while working on this - i.e. how plugins could exchange data / expose objects to each other).

[akien-mga]

Thanks!