Inline constructor support

[PathogenDavid]

Inline constructors are problematic to force export because we can't take a pointer to them.

In theory we can just make a trampoline function for them, but that's not The Biohazrd Way™. (This is probably what we'll do in the end for the sake of not relying on compiler weirdness.)

One of the things that I forgot about from the original PhysX prototype is that it requires PhysX to be built in debug mode or none of the constructors would be exported from the DLL. (The trick of simply calling them in the InlineReferenceFileGenerator output file didn't work outside of debug.)

At the time I did not investigate why this was, but knew it was a problem that would eventually need to be solved. (And forgot about it entirely until it ruined my life today.)

The reason the trick only worked in the first place was debug builds get /Ob0 specified. We could explicitly build the inline reference file with /Ob0, but this means functions called by the inline constructors would not get inlined. (This is what I'm doing for now though.)

We can get similar effects for everything that isn't marked as __forceinline with the following two pragmas:

#pragma inline_depth(0)
#pragma optimize("", off)

[PathogenDavid]

I've been revisiting this today and I think we're gonna have to go with the trampolines. I'm experimenting with a new more elegant implementation to InlineReferenceFileGenerator with InfectedImGui.

Currently I generate the inline exports file right before the static library resolver runs and then re-build InfectedImGui.Native so everything will be exported.

For libraries which do not wish to/cannot re-build their target library, we will instead recommend (and provide assistance for) building the inline exports file as its own DLL.

[PathogenDavid]

Finished in 23c4edd

Improving friendliness of constructing/destructing C++ objects in general is tracked by #161