[DO NOT MERGE] IRGen: add a hacky workaround to DLL Storage

[compnerd]

The runtime functions should not have DLLImport storage for the runtime
functions. Without this change, we would see swift_unexpectedError be
given DLL Import DLL Storage. It should probably be given DLLExport DLL
Storage. This is needed to repair the Windows build.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[compnerd]

I don't really know of a good way to handle this. Perhaps @rjmccall has some suggestions?

[troughton]

I was looking at this a few weeks back and couldn't come up with a fix, so thank you for this. As for a proper solution – I believe there was some discussion a while back on the swift-dev mailing list under the topic "swift (ABI) and Windows" which discussed propagating through the current module so this situation can be detected in a less hacky way.

[compnerd]

@troughton I don't think that this would work here. getRuntimeFn does not actually deal with SILFunction but rather llvm::Function. It goes and creates the LLVM Function in the Module. There is no associated SILFunction (that I can see). Maybe Im mistaken about the approach that @rjmccall was suggesting?

[rjmccall]

Why would it not be DLLImport? Is this specifically when building code that's going to be linked into the same DLL as the runtime?

[compnerd]

Yeah, it is going to be in the same module. In this particular case, we have swift_unexpectedError being materialized for swiftCore, and the definition ends up receiving the dllimport storage.

[compnerd]

The proper fix for this should be at #12353