Replace underscore with lodash, update backbone to 1.3.3

[sgtcoolguy]

JIRA: Related to https://jira.appcelerator.org/browse/TIMOB-24980
https://jira.appcelerator.org/browse/ALOY-1168

Description:
I originally planned to use Lodash's mergeWith to implement TIMOB-24980, but we use underscore. I can bring in lodash's mergeWith special for this case, and have in a separate PR #843

While this works, I think it'd be generally helpful to update our 3rd-party library here.

So, this PR proposes we:

• Add lodash 4.17.4
• Deprecate underscore.js
• Add Backbone 1.3.3, modify it to use lodash in place of underscore
• Set default backbone version to 1.3.3
• Use lodash's _.mergeWith to deeply merge the source mapper options and retain any user plugins/presets.

However, this is likely a breaking change, as there have been changes in behavior/method naming from underscore to loads, and we expose the library used as the _ global, so these changes propagate to the user's apps.

[sgtcoolguy]

I think if we do move this way we'll need to retain underscore (for older backbone usage), allow the user to opt in to using lodash, and possibly spit out a deprecation notice if using underscore or older backbone so we can migrate them forward. This is a helpful resource: https://github.com/lodash/lodash/wiki/Migrating

[brentonhouse]

@sgtcoolguy -- I wonder if lodash could be included in a /node_modules/lodash directory so that a developer could simply run npm install lodash@latest (or another version) to easily change the version of lodash that is used with the app?

[feons]

Why don't wee keep underscore or lodash as dev dependencies? So they stay under node_modules folder, and compiler codes don't need to require them like require('../../lib/alloy/lodash').

For that we also need to bundle another version of the modules under lib/alloy mainly for user apps.

[brentonhouse]

That would separate the underscore for compiling from the underscore for Alloy runtime, correct?

[feons]

@brentonhouse, yes that's right.

[hansemannn]

@sgtcoolguy I've made sgtcoolguy#1 to resolve the merge conflicts.

[feons]

I'm getting this error when compiling an app:

../alloy/Alloy/commands/compile/sourceMapper.js:69
	target.lines = getTextFromGenerator(target.templateContent, target.template).split(lineSplitter);

TypeError: getTextFromGenerator(...).split is not a function

[feons]

According to migrating doc, _.template syntax is _.template(string, option)(data)

[feons]

Now, jake test:all passed locally for me.

[feons]

But we still need to verify the generated code for controller that uses databinding, specifically the _.template usage.

[sgtcoolguy]

@feons I've merged titanium_mobile#9512, which means our current master branch is broken with alloy apps until we get this fix in (or disable some of the transpilation/hack the sdk).

I think it's important to move us forward here, though I realize it's not a great situation to force a breaking change to Alloy.

I'd love if anyone has any ideas how we may be able to hack babel's transpile to avoid this specific issue, cc @hansemannn @janvennemann @feons

Or did these PRs fix it? #868 and #870

[hansemannn]

@sgtcoolguy I know it's not an ideal solution, but I am all in for this, even as a breaking change. And also pro calling it "Alloy 2.0" - it's about time. If developers want to use an old version, they can. And even if we need to push CLI to the next major for his, I'd still agree with that. Getting ES6/7/8 support is the most fundamental gap we are closing right now, so let's push on that.

[ewanharris]

• Backbone 1.3.3 was added as part of ALOY-1534
• Moving to lodash is covered by ALOY-1168
• I have filed ALOY-1651
• From discussions we believe the use case that the mergeWith change aimed to achieve to now be possible

Based on the above I'm going to close this PR