Fix GLTF embedded texture not reimporting when changed

[Invertex]

Fixes #83154

The existing code skips re-extract/reimport of the embedded texture if an existing file at the extract path doesn't have a md5 value in the remap:generator_parameters section of its .import metadata, under the assumption the existing file wasn't an extracted version because it's missing it. But it wasn't writing the md5 value to the metadata when importing the first time, so this failed as a check.

---

Though I'm not sure this is a good long-term solution to tracking whether an existing texture is an extracted texture or not. I feel there should probably be more specific metadata related to this than just an md5, like an isExtractTexture bool and maybe an ownerUID entry...

[fire]

@lyuma you may want to take a look too.

[Invertex]

One existing potential issue I'm noticing is that the texture the model is referencing after import doesn't seem to be the extracted texture? It seems it's still embedding its own copy and referencing that, so any edits to the extracted texture will not be reflected on the model unless the material properties are edited on it. This seems like counterintuitive behavior?

But if it was updated to use the extracted version, that then brings up another issue. What happens when we edit the external one, but then the model goes through reimport at some point, the md5 will mismatch and the edited external version will be overwritten by the older embedded version. This is more unforeseen behavior we probably don't want.

So perhaps it would be good to then introduce another import option of Extract Textures + Overwrite Existing and rename the other to Extract Textures + Reuse Existing , so a user can decide their workflow, if they intend to continue editing a texture externally or updating it in the model file.

Or another proposal could be for an import option on texture files to mark them as not being allowed for overwrite by Godot import processes (other than its own import process of course)

[akien-mga]

Superseded by #86504. Thanks for the contribution nonetheless!