Add the the ability to iterate over Godot enums

[AndreLouisIssa]

I'm looking at the struct Mode (godot::engine::window::Mode) and I want some way to iterate over the pub const fields. Minimally, this would be an iterator over the keys (field names in the order they appear in Godot), and a map from key to value, which most naturally could be added to EngineEnum (godot::obj::EngineEnum) (or to sidecars).

I want to use this to automatically represent the window settings in an options menu without writing out a mapping manually.
I would still have to massage the names of the fields to be human readable, but this is usually quite easy (_ -> , convert to title case, create inverse mapping). I have previously used this approach in C# (Enum.Parse, Enum.GetNames) and Java (enum.keys), and AFAIK it was possible in previous Godot versions since enums used to be dictionaries.

In the long term it's probably better to just write the mapping myself, especially when eventually serialising and localising it, but it could be at least used to quickly generate the templates for those (although I could generate them from outside of gdext).

If this is already possible somehow, please add information about it to a section in the book or to docs on each EngineEnum or on EngineEnum itself.

[AndreLouisIssa]

Unrelated to actually implementing this feature, I realised that Mode is probably a bad example since it contains "Minimized" and a bunch of obsolete entries, so would need a lot of filtering anyway. I just hardcoded the 3 important values (Windowed, Fullscreen, Exclusive Fullscreen)

[StatisMike]

If Godot builtin enums would be in the future ported as actual Rust enums in gdext (if it is possible and viable) you could use on your end enum_iterator crate (as AFAIK Rust enums aren't iteratable at all in std)

[Bromeon]

@StatisMike This wouldn't work, as you can't derive traits on foreign types.

We would need to add such a dependency in gdext itself. And since both strum and enum_iterator depend on full-blown syn for a bit of parsing work, this won't happen.

But we already do all the proc-macro parsing ourselves anyway, so we can simply provide enum-enhancing APIs and design them in ways that integrate better with the rest of the library.

As an example, we already do this today with the IndexEnum trait (API docs).