Split C++ tests into raw and wrapper tests

[Rantanen]

I was looking into enabling exceptions and interface_wrappers tests for Windows and I'm struggling to find a clear way to do this - being a bit afraid of the #import test_lib.dll and #include "test_lib.h" conflicting with each other.

While it would be possible to have all of these tests under the same project/solution/whatever you want to call it, I would prefer the clarity of having every test in cpp-raw come with the same prelude and having the same support classes available to it - instead of opening a random.cpp file and then having to scan includes to see whether that specific file has stuff like CreateInstance available to it or whether it should use ClassFactory::create.

I'm proposing the following:

cpp-raw

• Minimal "external" requirements. (InitializeRuntime, UninitializeRuntime and CreateInstance).
• Use of raw interfaces in all of their terrible usability with raw HRESULT values, out parameters, etc.
• Goal is to ensure the Rust-C++ bridge works on a binary level.
• Compilation for as many targets as possible: Visual Studio C++, cmake GCC, possibly cmake llvm and cmake Visual Studio in the future.
• Intercom linkage in various ways: Visual studio #import, Intercom generated headers with dynamic loading, Intercom generated headers with static lib.
• This is not the "This is how we expect you to use Intercom" scenario. Instead this is the "If this doesn't work, then the nicer things don't work either" scenario.
• Perhaps platform specific code, such as ensuring GetErrorInfo/SetErrorInfo work on Windows, malloc works on Linux.

cpp-wrapper

• The full intercom-cpp dependency.
• Might be limited to "supported" use cases, such as inability to pass BStrs to wchar_t arguments (if BStrs are even supported through intercom-cpp).
• Compilation primarily through CMake - both for gcc and Visual Studio. We might provide a native VIsual Studio solution, but I don't see a need for it at the moment. We've already proven that native visual studio solution works with cpp-raw. Including a header shouldn't matter.
• Preferrably no platform specific code. The goal of intercom-cpp is to work on every platform.
  • Small bits like string handling might still be there since those seem to be inherently platform specific and we don't really want to prevent the platform specific use.
  • Stuff like GetErrorInfo/SetErrorInfo should be hidden behind a cross platform API under intercom-cpp which would use those methods for exceptions on Windows while something else would get used on Linux/elsewhere.

@Fluxie Opinions?

[Fluxie]

This was implemented in #63.

[Rantanen]

Great! I didn't even remember we had an issue for this. ^^