Style: Add class_db.h includes explicitly

[Repiteo]

• Helps address [TRACKER] Compile time issues caused by excessive includes #111218
• Related Core: Remove class_db.h include from ref_counted.h #116737
• Related Core: remove class_db.h include from resource.h #111573

During yesterday's core meeting, several topics were touched on with regards to the process by which we should be removing implicit includes for the comically-prevalent class_db.h. The current consensus seems to be that it's something that all Object subclasses rely on, so it would result in a fair amount of churn for the codebase when rolling out those changes. Tracking performance changes would also be tricky, as the number of files that actually need the include is hard to get a concrete answer for, even with the two above PRs in isolation (combined might paint a different story).

This stylistic PR is made with the intent of getting the churn itself over with as quickly and painlessly as possible. For every single implementation file that binds in some capacity, this PR adds #include "core/object/class_db.h explicitly. There are zero functional changes as a result of this PR, because every single one of these files requires this include to begin with. As such, this PR similar to #116539 (albeit much wider in scope), where it more clearly spells out the "problem" includes by going against the minimal-include default.

On a somewhat-related note: compatibility include order was brought up during the ClassDB core meeting topic, as it was discovered in #116737 that we cannot simply put class_db.h after *.compat.inc. Ivorforce suggested that we could just drop all those includes to the bottom of the file instead, something that godot-cpp already does. Since I'm already touching literally every single file that has those compatibility includes, as they're only a concept for Object subclass bindings, I tackled their migration in the same pass. This too resulted in zero functional changes, so it's similarly ignored within the same commit. EDIT: In the interest of keeping this PR free of blockers, I've instead implemented the #116737 approach of adding class_db.h includes to the *.compat.inc files instead

[Ivorforce]

I'm almost surprised to say but I'm fine with the class_db.h explicit include.
It's a great approach: Just add it to all the implementation files of Object subclasses. Makes for a real simple PR, and one that unlocks us from removing the include from headers much easier.

I'm not 100% sure about the .compat.inc. Both positions come with potential downsides: If it's at the start it cannot use the .cpp file's static functions, if it's at the end, the .cpp files cannot use compat functions (though perhaps they shouldn't need to?). Overall I don't have a strong preference for this which is why I haven't made an official proposal to change this so far. Maybe it would be ideal to actually have it be a separate .cpp file altogether, and one that only affects the header by declaring like _bind_compat_functions or something like that. But I'm not sure it's worth the churn to change it at all right now?

Anyway, enough rambling, i'd say it at least needs some separate discussion.

[Repiteo]

If the *.compat.inc are going to serve as a blocker in any capacity atm, then I'll save it for another PR & keep this focused on just the class_db.h includes.

[Repiteo]

Opted for the #116737 approach instead, where the *.compat.inc files themselves include class_db.h directly. A full revert would have meant more churn down the road when the include-order bug returned, so this nips that in the bud while keeping true to the main intent of this PR: explicit includes for everything requiring class_db.h

[Ivorforce]

Thanks for adjusting!