[TIMOB-26038] Use JavaScriptCore framework API to implement proxies

[sgtcoolguy]

JIRA:

• https://jira.appcelerator.org/browse/TIMOB-26038
• https://jira.appcelerator.org/browse/TIMOB-23504 - iOS: Titanium proxies don't extend Object.prototype properly

Description:
This is a technical spike that extends, cleans up, and formalizes what I was looking at in #10069

Basically, for some time now, Apple has had a supported mechanism for exposing native Obj-C classes/proxies to JavaScriptCore. It involves using protocols that extend from JSExport and then implementing those protocols in your classes. JavaScriptCore handles the grunt work of hooking up the methods/properties and converting types for you.

This PR begins migrating some of our proxies over using this mechanism and includes macros to simplify doing so, methods to handle dealing with conversions between new and old proxy types.

Some of the lessons learned:

• This simplifies the code quite a bit, but technically we could improve performance even more for constant properties by using the C API to assigns static values. (This and our old way basically use getters to wrap method calls to grab the property values).
• Ti.Buffer is special and allows indexed access to the contents. The new API has no means of doing this.
• When we expect to receive an "old-style" proxy, I had to typically hack the API a little to expect either id or JSValue* so that I can convert it. The JSC API doesn't know how to unwrap the old style proxies automatically itself. But as we move more proxies to the "new" style, we could do less of this and actually specify proper types.

[sgtcoolguy]

Note that I spent a lot of time/effort in making the commits/history super clean here. If we do merge this, it should be merged as "rebase and merge". Also, it should make it easier to review changes. The first commit lays all the ground work for hooking the new style proxies and uses them for a few core modules. The following commits are for converting other top-level modules over one by one.

[sgtcoolguy]

Interesting to note that the test for expecting a native error to be thrown when trying to set Ti.Geolocation.accuracy to null is failing because it no longer throws an Error! I'm curious how it's handling trying to convert null over under the hood (since the method/property is assigned the type CLLocationAccuracy which is a double).

Update: Turns out it treats null as 0, which I guess makes sense as Number(null) == 0.
And more fun: setting to 'abc' converts to NaN in JS and Obj-c worlds. So this still doesn't throw an Error unless we specifically do some checking natively ourselves here that !isnan(value); (https://stackoverflow.com/questions/719417/determine-if-nsnumber-is-nan)

So, I guess lesson to take away here is: moving this way leads to more liberal type coercion that matches JS spec (so is probably more correct) - so should probably also involve additional checking natively by us to throw exceptions if there's specific oddball values we don't want to allow like NaN, or values outside enumerated values, or limiting to integers/positive/negative, etc.

[janvennemann]

@sgtcoolguy What's the plan here on how much you want to move over to JSC? All of it immediately? Just a bunch of our proxies at first that are easiest to convert? Will we be able to completely replace Kroll with this?

I also started some experimental work with a new Hyperloop version that tries to use JSC as much as possible and integrates our metabase to workaround the runtime restriction of JSC. Would be a perfect complement to this.

[sgtcoolguy]

@janvennemann My initial goal was to explore this as a tech spike, and I think the earlier PR and Han's feedback sealed that this looked like a promising direction to go.

So for now, I'm iterating on this and attempting to get a good subset of the proxies moved over and still have the unit tests pass (and a nice clean commit history). I think once I've got a substantial set migrated (say, the modules already done above, plus Ti.Blob and Ti.Filesystem?) and the tests all pass, I'll put this PR up for merge review.

It's really up to us, @vijaysingh-axway and @mukherjee2 to decide on the sort of timeframe for this. My goal was to allow us to move this way "silently" (i.e. without impacting native modules or introducing any noticeable changes). If we can do so, then the first chunk might be able to land in 8.0.0, and we could continue to migrate more as we went. I think there's just so many APIs, it's not entirely feasible to move everything over at once.

[janvennemann]

Partly moving over to this for 8.0.0 sounds good. Maybe we can even deprecate the "old" way of creating modules and proxies in favor of the new JSC way with 8.0.0.

[sgtcoolguy]

So, this PR is growing quite a bit - even if I'm trying to be good about structuring the commits. I think it'd be good to get view from @janvennemann and @vijaysingh-axway now and try and get this chunk in.

The only thing I worry about is the refactoring obviously changes the type hierarchy of these proxies. I think generally that should be ok as move native modules don't actually use any of these types, but TiBlob/TiFile might be used by them. So perhaps I should hold onto my TiBlob conversion here and we do that later? Or maybe, we say "oh well" and merge it in to 8.0.0 but don't bump the module api version because it's probably pretty unlikely many (or possibly any) native modules use TiBlob?

[janvennemann]

Alright, i added a few notes, suggestions and questions. Man, this thing is a beast!

[janvennemann]

Added another round of feedback

[janvennemann]

Calling managedValueWithValue:andOwner: will already register the object with the virtual machine so explicitly calling addManagedReference:withOwner: is unnecessary.

Have you checked that you really need managed values here? Adding the callback to an array should retain it and keep it's JSValueRef from beeing GC'ed

[sgtcoolguy]

It's entirely possible we don't need a managed value here...

addressed Jan's feedback