[fix] Preserve typed external data references in decompiler

[sampletext32]

Hi.

While I was reversing an old game engine consisting of several dlls I've encountered an annoying quirk.
Ghidra does a decent job of creating thunks, crossreferencing them etc. But dlls (and not only them) can actually export and import variables, and unfortunately Ghidra did pretty bad there.

Essentially what I've encountered was a giant vtable of math functions focusing on SSE and processor support, and that vtable is heavily used outside of the declaring dll. I had to manually comment and override signature for all callsights. Pretty annoying huh.

The 12.1 version produces this:

Setting a type for this global did absolutely nothing.

So I spun up codex with the research task.
Turns out, while Ghidra did allow setting a datatype to the global, it never passed the datatype to the decompiler engine.

After a few iterations I got this:

Now I just have to create like a hundred funcdefs, but that's another story.

I made sure to follow the contribution guide, checked the code (it seems reasonable enough to me), compiled locally on windows, and stripped the pr of everything unrelated.

Open to comments and suggestions)

---

relates to #2206, #5711

---

below is ai description

---

Summary

• Preserve the local import pointer data item when resolving external references for decompilation.
• Use that local pointer datatype as a fallback when the ExternalLocation has no explicit datatype.
• Encode optional datatypes on HighExternalSymbol and decode them in native ExternRefSymbol.

Motivation

Imported external data references can carry useful user-applied types on the local pointer data item, while the ExternalLocation remains untyped. Without passing that type through, the decompiler falls back to generic code-pointer casts for imported function tables.

Validation

• Verified with: .\gradlew.bat assembleAll -x ip

[sampletext32]

rebased onto latest master