Address concerns with injected properties feature

[slindberg]

This addresses issues raised in the comments of #5162.

• remove unnecessary hasOwnProperty check
• make lazyInjections private
• remove unnecessary closure in InjectedProperty func
• name anonymous functions for better debugging
• remove injection type validation from production builds entirely
• added onLookup factory hook
• cache lazy lookup validation

I haven't addressed the top two concerns yet because I'm still uncertain of how the container should be treated within Ember. I'm also not 100% sure about the onLookup API, e.g. whether it should be a hook or a callback mechanism.

[slindberg]

@rwjblue does this look right to you to avoid defeatureify nesting problems? There's a Ember.assert inside a Ember.runInDebug inside a Ember.FEATURES.isEnabled...

[rwjblue]

Looks good to me. Sorry for the odd hoops to jump through here, but I absolutely appreciate the effort.

[slindberg]

The more I think about how the container validation currently works, the less I like it. I would love to implement a callback mechanism on the container like @stefanpenner suggested, but I can't see how that would work, mainly because Ember Object classes live in a world that is unaware of the container. The first time class code is aware of the container at all is on first instantiation by guessing at its own container property – ew.

Given that I can't come up with a better solution at this time, I've prepended an underscore to the two factory hooks that this feature has added to the container so they are officially private: _lazyInjections and _onLookup.

/cc @tomdale @stefanpenner @rwjblue