Use ScriptExportMode enum in EditorExportPreset

[Mickeon]

While making #107143 I discovered that for some ungodly reason EditorExportPreset's get_script_export_mode has been exposed to return an integer, not a value from ScriptExportMode, which was exposed for this exact, singular purpose. This PR fixes that.

This probably breaks compatibility and I am not sure who can review this. Does it count as a fix or an enhancement?

[Mickeon]

I don't think this is necessary but...?

[Bromeon]

Does changing from int to enum actually break binary compatibility? Seems to me that the FFI representation should be the same 🤔

Or is this a shortcoming of the compatibility mechanism, which treats enum and int as different?

(Obviously it does break source compatibility in situations where GDExtension bindings generate strongly typed enums, but the compatibility is mostly to allow 4.2 extensions to run under 4.4, which should be possible without registering a compatibility method.)

[raulsntos]

Does changing from int to enum actually break binary compatibility?

It does for the C# bindings. And the compatibility method would not prevent it, because C# does not allow overloads on the return type.

[Mickeon]

Rebased.
We still need to determine whether we should break compatibility for this (and potentially how to mitigate it in other ways?)

[Repiteo]

I think compatibility breakage in this scenario is warranted, but hearing some second opinions would be nice

[KoBeWi]

Reminds me of #108559

The breakage is only relevant when someone had used the method, no? It seems very niche, it's likely fine to change it.

[aaronfranke]

As long as the compatibility breakage is deemed acceptable, I approve of this.

[dalexeev]

This is a fairly small change, which amusingly requires quite a bit of boilerplate (but is still valid and worth noting). I don't think many users were concerned about the method returning int instead of ScriptExportMode, much less be affected by this change.

In terms of compatibility, in GDScript int is compatible with any enum, so narrowing the return value of a non-virtual method should be safe.

[Repiteo]

That's a healthy enough sample size to move forward with a merge (after rebase)

[Mickeon]

Rebased.

[akien-mga]

Needs another rebase. The fast-moving compat file is annoying.

[bruvzg]

The fast-moving compat file is annoying.

Maybe we should reorganize it, it's a constant waste of time since it's always required in applying both changes, and there's no real conflicts to resolve.

If it is one file per-PR it should not cause conflicts: like misc/extension_api_validation/4.5-stable/{PR_NUMBER}.expected, instead of a section in the same file.

[akien-mga]

Thanks!