iOS Parallel build tweak

[sgtcoolguy]

I did some local timings for iOS build. The slowest part is clearly the xcodebuild invocation. I think moving to pre-compiled frameworks may be able to help speed that up somewhat.

However, I did see that producing the logo set and copying JS files were being run in series when they could be run in parallel (and those two are the other largest chunks of time in our build).

So here are my totally unscientific timings here on clean builds of the mocha test app:

master: 35-38s
next: 30-31s
next w/ framework (#10218): 27-31s
next w/ parallel-build (this PR): 24-29s
next w/ framework & parallel-build: 22-23s

Specifically this PR tries to run writing the app props, handling JS files, copying CSS files and handling the images/resource files in parallel now (where before we ran it all in series).
We still run the image manipulations/functions and copying resources in series. The big win here is running all of that in parallel with the JS file copying/parsing/writing as we shave off a few valuable seconds.

[build]

	Warnings
⚠️	There is no linked JIRA ticket in the PR body. Please include the URL of the relevant JIRA ticket. If you need to, you may file a ticket on JIRA

	Messages
📖	👍 Hey!, You deleted more code than you added. That's awesome!
📖	💾 Here's the generated SDK zipfile.

Generated by 🚫 dangerJS

[cb1kenobi]

CR'd and looks good. The iOS build is just begging to be async/await'd.

[hansemannn]

The improvements are massive, wow! One thing that always takes like 5-6 seconds is that when we use appc xxxx, it checks all entitlements before even doing anything else. We should check that in the background and let the build proceed to not block them for e-v-e-r-y build. It's also the main reason I prefer the ti CLI for all sim-builds.

[cb1kenobi]

@hansemannn It only checks entitlements once a day. Once that's done, the Appc CLI adds a few seconds of overhead on top of the Titanium CLI, most of which is file I/O (require() calls, config files, etc).