Move library to C instead of C++

[Ruhrpottpatriot]

Problem: Having the library written directly in C++ is good, when the client uses stdlib themselves. Yet as soon as the client uses their own version of certain types (e.g. UE4s smart pointers) interfacing with each other becomes much harder and often involves converting the type from C++ to C and then the clients version of the type. Another solution would be to forego the client types altogether and stick with stdlib, which sometimes isn't possible

Solution: Move the C++ implementation to C. Since C is the least common denominator in most cases many libraries would benefit from a singular codebase (e.g. UE4, Android, Swift users). In addition clients, who implement their own versions of certain C++ std types, more often than not accept plain C types as arguments.

[Dimon4eg]

The nakama-cpp is written in C++ but has also C API. Please read https://github.com/heroiclabs/nakama-cpp/blob/master/README-C.md

[novabyte]

@Dimon4eg I think what @Ruhrpottpatriot has brought up is whether we should reframe the client to prefer the C API and either drop the CPP code or de-emphasize it in the codebase. We should have a chat about it.

[Ruhrpottpatriot]

The issue came up in chat, when I was asking about the api having differences between C and C++. A bit of history: I had begun writing an UE4 OnlineSubsystem with Nakama and was using the C++ API directly. However, more than once I found myself converting from C++ to plain C and then back to UE4. Now, in the last week Epic released their EpicOnlineSubsystem SDK, which is written in plain C, to the public. This meant, that the SDK - programatically - integrated very well with the UE4 C++ code, and it's not limited to UE4.

[lugehorsam]

For Unreal functionality, rather than rewrite the client in C we have since updated the nakama-unreal client to use Unreal's C++ type system.