Add a generic JSPromise implementation

[MaxDesiatov]

This provides three overloads each for then and catch, and I'm not sure if that's good for the type-checker performance and usability. I was thinking of naming the promise-returning callback version flatMap, but ultimately decided against it.

then overload with two callbacks is not available, because it's impossible to unify success and failure types from both callbacks in a single returned promise without type erasure. I think users should just chain then and catch in those cases so that type erasure is avoided.

[kateinoigakukun]

If fail to construct, we should throw error or report it with a detailed message. Force unwrapping fatal messages is not quite useful to see the error reason for JavaScriptKit users.

[kateinoigakukun]

Please note that this class must have the same lifetime with the actual Promise object in JS environment because callback handlers will be deallocated when JSPromise.deinit.

If the actual Promise object in JS environment lives longer than this JSPromise, it may call deallocated JSClosure.

[j-f1]

I just had an idea: what if the JSPromise class exposed an ObservableObject? We could have some code on the JS side that would attach itself to the promise and tell Swift to update either the value or error property without having to worry about managing Swift closures.

[MaxDesiatov]

That will require a dependency on OpenCombine unfortunately, and it would be best to keep JavaScriptKit the lowest level library in the stack if we ever hope to achieve #61. What about a separate OpenCombineDOM library that allows any JSPromise to become a publisher, and then exposes fetch and timer publishers too? Yes, this multiplies the number of libraries, but the JS ecosystem is fragmented (read "modular") anyway, and we'd have to reflect that to allow users to mix and match what they intend to use in their apps.