Don't compile advanced Control nodes if disable_advanced_gui is on

[YeldhamDev]

This PR is a little intrusive I'm afraid. It does two things:

• Moves files of Controls that are categorized as "advanced" to a folder called, well, "advanced". Due to this, a lot of files are touched to updated the path for header includes.
• Makes so that those files aren't included when disable_advanced_gui is turned on. Before, it just didn't register the classes.

Here are the size comparasions. GNU/Linux, release templates (this time dev_build is turned off as well. 🙃). It saves almost 3 MB:

Default	No Adv GUI
78.0 MB	75.2 MB

Sponsored By: 🐺 Lone Wolf Technology / 🍀 W4 Games.

[Calinou]

This makes sense on the surface. I'm hoping it doesn't break GDExtension compatibility though.

[Calinou]

Tested locally, it works as expected.

Binary size for a stripped Linux x86_64 release export template with LTO (scons platform=linuxbsd target=template_release optimize=speed lto=full):

• master: 72,031,960 bytes
• This PR: 72,036,056 bytes (+ 5 KB)
• master with disable_advanced_gui=yes: 69,324,408 bytes
• This PR with disable_advanced_gui=yes: 69,099,096 bytes (-225 KB)

[akien-mga]

I tested this and I don't think the gains are worth the awkward advanced/ subfolder and breakage. Most of this code already gets stripped by the linker due to it not being registered for use (using the same principle as engine build profiles), so this doesn't do much (aside from possibly decreasing compilation time a bit, as we avoid compiling objects just to discard them at link time).

Here's my test results for this PR and master (Linux x86_64 template_release with production=yes):

Branch	disable_advanced_gui=no	disable_advanced_gui=yes	Difference
master (4248411)	70.25 MiB	67.50 MiB	-2.75 MiB
This PR (915e960)	70.12 MiB	67.18 MiB	-2.94 MiB

So the changes in this PR only strip an extra 195 KiB, which is IMO not worth breaking all PRs and well-used include paths for.

In fact, this option predates the build profile feature, and arguably isn't particularly well designed nowadays as it just removes an arbitrary set of control nodes, some of which may be needed for games which aren't GUI heavy (e.g. RichTextLabel). Build profiles (once made to reliably detect what a project uses) should be much finer and more useful.