Move 2D and 3D resources to their own folders

[aaronfranke]

Similarly to how we have the scene/2d folder and scene/3d folder for 2D and 3D nodes, this PR moves 2D and 3D resources to scene/resources/2d and scene/resources/3d. Also, I moved the skeleton modification resources to another subfolder, scene/resources/2d/skeleton since there were 18 2D skeleton modification resource files. Resources that are shared between 2D and 3D are still in scene/resources.

• This gives us the ability to easily exclude the resources in these folders when disabling 2D or 3D (but as of this PR, they are always included).

• In terms of compiled size, as of the current master, the resources folder is the biggest one, so that's another reason that I think it would be nice to divide it up into 2D and 3D subfolders:

[clayjohn]

SurfaceTool and MeshDataTool should be under /resources rather than /resources/3d. Both can be used in 2D as well as 3D. For example, they can be used with a MeshInstance2D or a MultiMeshInstance2D.

[aaronfranke]

Awhile ago this was brought up in a meeting (should've written this down then, but I forgot), and reduz wondered if instead we should have 2d/resources instead of resources/2d. The challenge here is that there are some resources that are neither 2D or 3D, so we would still need a resources folder. I am proposing this PR as it is because this is the path of least resistance vs the existing codebase, since these files are already in resources, this PR just adds another subfolder, but I am good with either approach, so whatever is preferred we can do that.

[akien-mga]

After discussion with maintainers, I agree with the change.

Conceptually, this is fine, a 2D/3D split marginally helps make the code organization better, but also paves the way to more possibility to decrease build size in custom 2D/3D only builds.

My main concern is with breaking compatibility on the include paths for C++ modules which use those Godot resources.

• For modules which only track a single Godot version (like in-house C++ modules for game-specific logic, etc.), it's fine, the devs can just do the same refactoring when updating to Godot 4.3.
• For general-purpose open source modules which aim to support multiple Godot branches, it's a bit trickier. They can still wrap things with #if VERSION_HEX >= 0x040300 checks, though that implies including core/version.h in all affected files. Thankfully with GDExtension/godot-cpp, such modules are less common than they were in 3.x, so I think the tradeoff is acceptable (compatibility is not broken for godot-cpp as their the include paths are all flattened to a single folder).

[akien-mga]

Thanks for the work and your patience :)