[GLIMMER] Ensure the view registry is propagated.

[rwjblue]

• Add an injection to ensure that component's all get the -view-registry:main injected.
• Replace usage of Ember.View.views as the fallback registry, with a custom fallback registry that is only used when views/components are instantiated outside of the DI system.

[krisselden]

should not be injected to every component, only the renderer and eventdispatcher need this.

[rwjblue]

@krisselden - Sounds good. Will update.

[krisselden]

The renderer can register a view and the event dispatcher looks it up. Putting _viewRegistry on every component then dereferencing it up via every component is crappy.

[rwjblue]

@krisselden - Components (in HTMLBars) currently have a _viewRegistry property (and in fact this is how the registration happens in view_support mixin's register method), should I change that to have the renderer itself register views? If yes, should that change be applied to both HTMLBars and Glimmer?

[krisselden]

the dom state should call register on the renderer, I don't think the fallback registry is important. I think it is cruft from when views may or may not have had an env and/or Ember.View.views

[rwjblue]

@krisselden - OK, updated to avoid threading the view registry around, and instead rely on the renderer to do the work.

[rwjblue]

Removed this test, since it is asserting a thing that is actually not valid (we do not want a _viewRegistry set on view/component instances at all).

[chadhietala]

@rwjblue Does this properly enable #13505?

[krisselden]

@chadhietala only in the sense that the test has been removed.