Figure out what to do with VARIANTs in raw type system

[Rantanen]

Currently not supported. Should we support these?

Support would require multiple raw VARIANT structs, which differ on the string types - and possibly the array types in the future.

Currently all interface pointers within VARIANTs are of Automation type system, but this is somewhat easy to change.

One proposal is to have

VARIANT_raw and VARIANT_automation structs. VARIANT_automation is the same as Microsoft's VARIANT struct. VARIANT_raw would replace BSTRs with char*s, etc. Rust would need to define both of these raw structs. The friendly intercom::Variant would then implement conversion into and from both of these.

The low level parameter support would come just by having the tyhandler::VariantParam defining the underlying com_ty as the respective raw struct. We'll use into/from and com_into/com_from for conversions anyway so that should magically just work once the com_ty handles the type system.

The big downside here is that we'd need to come up with two different names for these in intercom-cpp. The global VARIANT is already reserved in Windows programming so that kind of needs to stay. On the other hand Intercom-cpp might want to use intercom::VARIANT as the raw version, which is more likely to be used with intercom C++ code anyway.

Or should we have intercom::VARIANT_raw and intercom::VARIANT_automation as the two concrete types and then some flags to define which typedef intercom::VARIANT into one of those?

[Rantanen]

Implemented with ExternType, the raw::VARIANT is now raw::VARIANT<TS> that mainly alters the interface pointers.