Handle `size_t` length arguments properly in ClientKit wrapper.

[rpavlik]

Lines I'm talking about:

• length as an output parameter: https://github.com/OSVR/OSVR-Unity/blob/master/Managed-OSVR/ClientKit/ClientKit.cs#L41
• buffer length submitted as input parameter https://github.com/OSVR/OSVR-Unity/blob/master/Managed-OSVR/ClientKit/ClientKit.cs#L44

The corresponding C methods those invoke are here: https://github.com/OSVR/OSVR-Core/blob/master/inc/osvr/ClientKit/ParametersC.h

Note that those are actually size_t which is platform dependent, and which I think we can assume is the same as uint_ptr_t. size_t is the idiomatic type to use there from a C and C++ perspective, so if reasonable I'd like to leave those signatures alone. However, it poses an issue to the .NET bindings. It looks like there's a way to handle it properly. If it turns out to be unfeasible, we can change those to uint32_t if needed, since that should be a big enough type, but if a solution isn't too hard that's just in the .NET stuff I think that's probably preferred.

Here are the links I've collected related to this issue.

• http://stackoverflow.com/questions/2632458/can-a-net-application-targeted-for-any-cpu-use-p-invoke-calls-in-multiple-env
• http://stackoverflow.com/questions/772531/net-equivalent-of-size-t
• http://blogs.msdn.com/b/jaredpar/archive/2006/04/12/575011.aspx
• http://blogs.msdn.com/b/jaredpar/archive/2006/04/13/follow-up-pinvoke-with-32-and-64-bit.aspx - I think this is probably the most important one
• http://dotnetdebug.net/2006/04/17/pinvoke-and-memory-related-issues/

[rpavlik]

OK, this has been done in the new separated-out https://github.com/OSVR/Managed-OSVR repo, so once we port to there, it will just be some build system changes.

[rpavlik]

Going to consider this closed, since other issues refer to the build system changes.