GDExtension: Clean up types for new classdb_register_extension_class6

[dsnopek]

This is a follow-up to #118214 (a new feature for Godot 4.7 by @Ivorforce), in order to make it more consistent with how we've handled these changes in the past

The main change is making GDExtensionClassCreationInfo6 into a "struct" rather than an "alias" for GDExtensionClassCreationInfo5 so that it can explicitly take the GDExtensionClassCreateInstance3 type

At a binary level this is equivalent to what was added in #118214, however, I think the important distinction here is the semantic difference between GDExtensionClassCreateInstance2 and GDExtensionClassCreateInstance3, and so I'd prefer if it were documented in those terms, rather than just a note on classdb_register_extension_class6. This allows us to document the latest thing, rather than using a reference to the previous thing. I think this will be more "evergreen" as we continue to iterate and inevitably make new versions of this interface function and struct

This ends up having some follow on effects and I also did some small clean-up too:

• The description for the create_instance_func wasn't great, so updated it on GDExtensionClassCreationInfo6 which is added in this PR, but then for consistency, I copied it to the older structs
• The ClassCreationDeprecatedInfo now takes the function pointer rather than a boolean flag (and everything is non-legacy when all fields on this struct are zero)
• GDExtension::_register_extension_class_internal() now takes a GDExtensionClassCreationInfo6 and all the deprecated functions work in terms of that struct now
• There were a whole bunch of stale comments giving old types or field names which I've updated

Given that this is a new Godot 4.7 feature, and we don't want to change the gdextension_interface.json in patch releases, I think this qualifies for merge after the feature freeze :-)

[Ivorforce]

I don't have a strong opinion on the shape of this change (whether it is a separate struct or an alias).
I usually choose the most minimal change, but I'm more than happy to support David if he prefers this form of the API.

Code looks good to me.

[Repiteo]

Thanks!