Fix Windows codegen (LLVM globals) in non-singlemodule mode

[oprypin]

(the suggestions for root causes and fixes all come from @RX14)

Windows compilation so far was always being done in --single-module mode because --cross-compile implies it. But if one adds enough workarounds to try out the compiler on Windows, they would run into these problems, unless --single-module is specified.

1. __CxxFrameHandler3 is being added only in the main module but can be used in any other module, and the attempt would cause an error:

   Undefined llvm function: __CxxFrameHandler3
   

   Instead, define this function once per module (still on-demand).

   https://gitter.im/crystal-lang/crystal?at=5e7ce5b3bf65703264de4711

2. void_ptr_type_descriptor is being defined as an LLVM global once per module. But because it's the exact same symbol in all the modules, linking them together leads to this error (repeated per module):

   I-O-5858F-ileD-escriptor43.o : error LNK2005: "void *`RTTI Type Descriptor'" (??_R0PEAX@8) already defined in _main.o.
   

   Instead, define it only in the main module (still on-demand) and then let other modules refer to it as an external constant.

   https://gitter.im/crystal-lang/crystal?at=5e80a76fd71a6e7e8d7efa55

[bcardiff]

The other alternative would be to declare types in the crystal land and access their representation. Allowing the current mecanism to use the type in multiple modules. But I'm fine with the PR as is.

[RX14]

The other alternative would be to declare types in the crystal land and access their representation

It's actually impossible to represent these types as crystal constants, because we don't support emitting constant math expressions to LLVM (see sub_image_base, Crystal would codegen this as a method call).