Replace hardcoded radial center cross marker for `TextureProgressBar` with internal `Marker2D` child node

[arkology]

Updated after separating 1) replacing hardcoded marker and 2) issues with its visibility in plugins.

This is proof of concept showing how https://github.com/godotengine/godot-proposals/issues/11225 may be implemented, nothing more.

How it looks:		Current	PR
1024x1024
48x48

Pros: 1) Crosshair now doesn't look unnatural compared to other stuff in editor. 2) Reusing existing functionality of Marker2D node. 3) Allows seeing actual center more precisely - may be good for low-res art.

Cons: 1) Additional overhead in editor as additional node is created. 2) Less code readability, too overcomplicated.

Implementation details:

• If the code is executed in the editor, an additional internal Marker2D child node will be added when TextureProgressBar is created.
• When setting fill_mode, Marker2D node visibility changes. It becomes visible if mode is radial and texture_progress is valid. ~Also these is check if Marker2D node is valid as it could be freed (to cover issues https://github.com/godotengine/godot/issues/46266 and https://github.com/godotengine/godot/issues/96859).~ <- Not applicable anymore, now this PR is targeting to show only visual changes.
• When drawing, position of Marker2D node is updated.
• Visibility of Marker2D is also changed inside set_progress_texture().
• Changes are reflected in TextureProgressBar node description in docs. UPD: All mechanism around removing reference cross in plugins could be ignored, now this is not targeting to fix this issue.
• Previously position of hardcoded radial center marker was rounded to the largest whole number. Now this rounding is removed and position of Marker2D is real radial center position. - This one could be moved into any other alternative of current PR.

[Mickeon]

I'm not... necessarily against this but it would be a whole lot less code to just draw what the Marker2D node draws, wouldn't it? This feels over-engineered. Even the additional note in the docs is over-engineered.

[arkology]

The simplest way will be just to add property to show/hide this reference cross. But this reference cross will stay hardcoded (which is not good IMO) and this property will be present in release builds (please correct me if there is possibility to make editor-only properties).

I'm not saying that current PR is the best that could be done, it's just possible option. First of all this is just concept of how it may be changed to gather any feedback. Most likely this PR will be stalled (2 issues in ~7 years - not high-priority problem at all) and I'll close it later.

Upd: I've added possible alternatives into feature proposal

[Mickeon]

and this property will be present in release builds (please correct me if there is possibility to make editor-only properties).

There are precedents. For example: https://github.com/godotengine/godot/blob/0c45ace151f25de2ca54fe7a46b6f077be32ba6f/scene/main/scene_tree.h#L140-L144 https://github.com/godotengine/godot/blob/0c45ace151f25de2ca54fe7a46b6f077be32ba6f/scene/main/scene_tree.h#L350-L368

Notice how in every other build other than debug the getters always return false (which the compiler likely optimises out). Yeah, the property should still be bound, but its getter and setters can be coded to do nothing.

I do find that reusing Marker2D for this is kind of clever but my personal concern still stands.

[Mickeon]

Also, wait. Wouldn't Node.is_part_of_edited_scene() also solve the original issue?

[arkology]

Also, wait. Wouldn't Node.is_part_of_edited_scene() also solve the original issue?

I'll try this method, thanks!

[arkology]

@Mickeon thank you so much for referencing to Node.is_part_of_edited_scene(). This solves issue as expected.

[arkology]

So, this PR is now just showcase for replacing hardcoded reference cross with Marker2D (i.e. possible solution for feature request), nothing more. This one will not close (is not targeting to close) mentioned issues with reference cross. I'll open separate PR to replace Engine::get_singleton()->is_editor_hint() with is_part_of_edited_scene() which will close original issues. And then update first comment of this PR with some gifs and then close it. Sounds like a plan.

[arkology]

Updated OP with some clarifications and gif, closing now. Still could be tested (at least for now) by downloading PR artifacts if anyone is interested (click Commits -> Artifacts)