Change bit field enums to use uint64_t as underlying type

[mihe]

Fixes godotengine/godot#85444.

As discussed in the issue above, this would change the underlying integer type for enums declared with VARIANT_BITFIELD_CAST to be uint64_t instead of the default int.

This helps resolve an issue where MSVC will currently truncate any enum values larger than 2^31 for enums that don't have an explicit underlying type, which is affecting RenderingServer::ArrayFormat, as seen in the issue above.

Note that this technically opens up for other potential future problems, where someone on the Godot side of things could define a regular int-backed enum, bind it with VARIANT_BITFIELD_CAST and then include it in something like a GDREGISTER_NATIVE_STRUCT, which would lead to an ABI difference and potentially memory corruption.

[akien-mga]

This looks good to me as a short term downstream solution.

I agree we should aim to get this information in the API json itself, or document clearly that is_bitfield always means uint64_t and should be interpreted as such by bindings.

[dsnopek]

Personally, I feel like we should be saying that all enums are backed by a 64-bit integer, since we are already saying that they are always encoded (when passing as an argument or return value) as a 64-bit integer.

Unfortunately, there is the case with GDREGISTER_NATIVE_STRUCT() that @mihe points out, where enums can be used without passing through our usual encoding mechanism, and the existing CaretInfo struct that uses an enum, and so saying all enums are 64bit would break the ABI on 32-bit builds. Also, GDREGISTER_NATIVE_STRUCT() is technically using C structs (not C++) and (as best I can tell via Google) the C standard defines enums as being int-sized and we can't explicitly set the backing type, so we'd probably also need a rule that says we shouldn't use enums in GDREGISTER_NATIVE_STRUCT()s. This definitely needs more thought and discussion in general!

In any case, I also think this fix is fine for now. :-)

[akien-mga]

Thanks!