Fix #23731 - undefined __xopEquals/__xtoHash for instantiated struct

[dkorpel]

Closes #23731

Claude's description:

Bisected to 786dc71 ("Emit special __xopEquals/__xopCmp/__xtoHash members once"), which removed the emission of those members from TypeInfoStructDeclaration codegen on the assumption that they are always emitted along with the StructDeclaration in some other object file.

That assumption breaks for a struct template instance whose needsCodegen() is false but whose TypeInfo is still emitted here (isSpeculativeType returns false when ti.minst is set or sd.requestTypeInfo is true):

• ti.minst is null — a speculative instance whose TypeInfo was requested anyway (e.g. by the inliner, which sets requestTypeInfo with a null scope). No module ever runs TemplateInstance.toObjFile() for it.
• ti.minst is a non-root module that is not part of the compilation — as in the reported case, where the instance is created while CTFE-evaluating a manifest constant in an imported module that is never itself compiled.

In both cases the emitted TypeInfo_Struct ends up referencing __xopEquals/__xtoHash symbols that no object file defines, giving the reported link errors. This restores the pre-2.113 emission next to the TypeInfo; the functions are COMDATs, so a duplicate copy in the module that does emit the instance is harmless.

Note the reduced case in the issue also fails to link with 2.112 and 2.110 on the separate ModuleInfo for config error, which is the long-standing "all imported modules that need a ModuleInfo must be compiled and linked" requirement and is unrelated to this regression.

[thewilsonator]

Is this good to go?