[BREAKING BUGFIX] Do not assume null Ember.get targets are all globals

[mixonic]

Some bugfixin'.

• Changes globals to only mean properties starting with $ or a
  capital letter.
• Changes normalizeTuple(obj, 'Foo') to resolve Foo as a global. This makes the behavior consistent with normalizeTuple(obj, 'Foo.bar') which already resolves Foo as a global (and looks up bar).
• Changes normalizeTuple(null, 'Foo') to resolve Foo as a global.
• Specs normalizeTuple('null', 'foo') to resolve to [undefined, ''].
  This is unfortunate but needed to keep getPath happy.

This code is old, and tricky to modify due to perf optimizations and edge case behavior. It would be great to refactor more heavily at some other date.

Fixes #3760

/cc @bantic @hejld

[wagenet]

I think we want to move this direction, but we also want to make sure we don't break existing apps. We'll have to think about this more.

[mixonic]

Tricky no doubt, but the code in master has some weird inconsistencies this cleans up. The biggest change is in normalizeTuple, but I doubt many apps consume that API. It doesn't even seem like it should be exposed, really.

Examples of bad behavior in master:

// Complex paths are normalized differently than simple paths
Ember.normalizeTuple(null, 'SomeGlobal.aProp'); //=> [SomeGlobal, 'aProp']
Ember.normalizeTuple(null, 'SomeGlobal'); //=> throws Invalid Path

Ember.normalizeTuple({some: 'obj}, 'SomeGlobal.aProp'); //=> [SomeGlobal, 'aProp']
Ember.normalizeTuple({some: 'obj}, 'SomeGlobal'); //=> [{some: 'obj'}, 'SomeGlobal']

window.koo = { joo: 'soo' };
Ember.normalizeTuple(null, 'koo'); //=> throws Invalid Path
Ember.normalizeTuple(null, 'koo.joo'); //=> [{joo: 'soo'}, 'joo']

// Non global paths are still treated as globals
Ember.get('length'); //=> the number of frames on the window
Ember.get(null, 'length'); //=> the number of frames on the window

Looks like I failed to clean up the names of several tests, pushing a fix for that shortly.

[stefanpenner]

👍 on this, but I share @wagenet's concern we will need to be thorough on this one.

[ebryn]

I think we should probably first add some deprecation warnings in the dev builds so we can ween people off the bad practices. That would help us also collect some additional tests for valid use cases that we might not have tests for.

[mixonic]

@ebryn I suggest another PR that raises deprecation warnings for null-target-non-global get calls, a with-target-but-global-path normalizeTuple calls. Sound right?

[mixonic]

Rebased on top of the ES6 branch and @stefanpenner's perf work

[mixonic]

Rebased again and tests passing. Still blocked on #4124.

[rwjblue]

The deprecations from #4124 and #4459 will be in the 1.8 beta series (ships in 3 weeks), I think this is probably good to merge just after 1.8 is branched. Any objections?

Will need to be rebased (and get the tests passing) before that though.

[mixonic]

Rebased. Yet another minor violation of semver from my hands if it goes into 1.x.

[mixonic]

Moved validateIsPath exception into its own function to keep AST size of normalizeTuple down, per @stefanpenner's suggestion.

[wagenet]

@rwjblue can we merge now?

[rwjblue]

@wagenet - Yes, I think so.

@mixonic - Can you rebase and add a [BREAKING BUGFIX] Changelog entry?

[rwjblue]

@mixonic - Needs a rebase, but we agreed that this was good a couple F2F meetings ago (in NYC).

[mixonic]

@rwjblue this passes, and I've updated the changelog. Let me know if you had something else in mind.

Excited to close this before it sits open for two years. This is probably the longest span of time between a proposed software change and its realization I have ever authored :-)

[rwjblue]

ZOMG ZOMG ZOMG