Refactor PlayroomKit

[momintlh]

This isn't a feature/bug issue but rather an issue for refactoring/cleaning the SDK. As we are using callbacks in many parts of the C# wrapper, it is getting quite messy, we have the following pattern in multiple parts:

private static Action SomeCallback = null;

[DllImport("__Internal")]
private static extern void InternalJSLIBFunction(Action callback)

// Callback Invoker
[MonoPInvokeCallback(typeof(Action))]
private static void CallBackInvoker()
{
    SomeCallback?.Invoke();
}

// Exposed Function
public static void ExposedFunction(Action callback) 
{
SomeCallback = callback;
InternalJSLIBFunction(CallBackInvoker);
}

And to use the function we usually do something like this:

PlayroomKit.ExposedFunction(() = > {
   // Do Something when callback is invoked
})

or

PlayroomKit.ExposedFunction(callback);
void callback() 
{
// Do Something when callback is invoked
}

What we can do is to make a custom class for handling callbacks this will simplify the current codebase and make it easier for future updates/fixes.

[SaadBazaz]

Yeah a class for Callbacks (kind of like a CallbackFactory or something) might be cool.

Also, can use Macros for repetitive code, like the if playroom is not initialized guard.

[momintlh]

Side by side working of JSLIB & C# handling callbacks:

[SaadBazaz]

We need better error handling to distinguish between JS errors and Unity errors. Inspired by #38

[SaadBazaz]

The current RPC implementation is unstable. Using setState to manage rpcEventNames can cause race conditions under high loads, and may not guarantee delivery (specially first delivery, as there will be network delay between setState and the RPC delivery)

This needs to be reliably managed. A way to do this is by delivering metadata alongside each RPC call, or use a predictable key generator to generate function IDs.

Reference:
#67

[SaadBazaz]

We also should separate our header and definition files, and give the project better structure and abstraction.
Not only will it make our maintenance much easier, but later it may give us an opportunity to build C#-native functionality.