Add check to ensure registered classes are declared

[AThousandShips]

Checks that all classes registered to ClassDB have been properly declared with GDCLASS

The error message fired is pretty clear IMO as it references the method called, like so:

core/object/class_db.h(190): error C2338: static_assert failed: 'Class not declared properly, please use GDCLASS.'
core/register_core_types.cpp(249): note: see reference to function template instantiation 'void ClassDB::register_class<ConfigFile>(bool)' being compiled

[AThousandShips]

If someone has pointers for what to put in the docs for the XR class I'd appreciate, only added because the class became registered, can be done separately

[AThousandShips]

Will also see about adding a similar check to godot-cpp if this method is desired

Edit: Doesn't seem to be an issue in godot-cpp, it fails to compile for classes without the macro regardless

[bitsawer]

Possibly fixes this too: #73936

[aaronfranke]

I tested this PR on a big project (The Mirror). Everything still works as before. Also, the editor startup time went from ~9.5 seconds to ~8.5 seconds. Wow!

I'm approving but this is just a "check if it works" review, not a code review.

[BastiaanOlij]

Ok, added some descriptions to include in the documentation XML.

[AThousandShips]

Thank you!

[akien-mga]

Edit: Moved question on OpenXRInteractionProfileMetaData naming scheme to #81037.

It would also make sense to split the fixes to the OpenXR class and the actual core check in separate commits. (OpenXR changes first, so that the core check passes.)

[AThousandShips]

Can split it off later today when I have time!

[AThousandShips]

Probably isn't as critical for 4.0 now but leaving the label for now, feel free to remove it if it isn't considered significant (it still matters for custom modules, but seeing how 4.0.5 is likely the last 4.0 patch it won't affect core much)

[AThousandShips]

Tested and works well for 3.x as well so if this gets merged I can open a 3.x version as well to ensure correctness, there's no missed cases in 3.x however based on testing it, and that without this check removing GDCLASS does not cause any compilation errors or runtime errors, at least not detectable by CI

[akien-mga]

Thanks!

[AThousandShips]

Thank you!

[YuriSizov]

Cherry-picked for 4.1.2.