Callbacks in class must be promises

[Julusian]

@nytamin you are going to love this 'fun' case that I've spent quite a few hours today digging into today.

Essentially, as it is right now, any callback passed into a ThreadedClass gets slightly mangled, so that it returns a promise.
If the class does not define in its interface that the callback should return a promise, this will lead to weird type issues, as it will be getting a promise anyway. eg testcase class normal-callback gets back a value of "[object Promise]5" instead of the expected 15.

This becomes quite a problem when the class is an EventEmitter, as it means that when the the parent does an .on on the threadedClass, if it throws an error in the callback provided to .on, then that error gets lost as an UnhandledPromiseRejection.
The expected behaviour here is for the error to get bubbled back to the emit.

I'm not sure how a solution to this will work. Somehow the callbacks passed in need to block the thread execution (fibers?)

[nytamin]

You're right, this is a real issue, and one that probably points out a fundamental flaw in the threadedClass.
Fixing it is probably not straightforward, perhaps fibers would be a solution as you suggest, but that might be a big refactoring to do.

I'm putting this on hold for now due to lack of time/resources, but if anyone would want to look into this, I'm all for merging it in.