This commit fixes several edge cases in how scope was managed in
templates, how attrs are looked up, and how views are cleaned up,
particularly the willDestroyElement user hook.

No longer requires `npm link` for HTMLBars.

…perties`.

In Ember.Handlebars helpers it is possible to add additional dependent
keys:

```javascript
Ember.Handlebars.helper('capitalize-name', function(value) {
  return get(value, 'name').toUpperCase();
}, 'name');
```

---

Unfortunately, the area that we know about the render node and can add
more dependent keys, had no knowledge of the individual helper being rendered.

Thsi commit adds a `findHelper` call to `linkRenderNode` so that we can
determine if additional dependent keys are needed. This is sub-optimal
because the additional `findHelper` may have a negative impact on render
speed, but a better solution is not currently possible.

Previously, the `TransformOldBindingSyntax` AST walker was only
processing `{{view}}` invocations. This change makes it process all
helper invocation, and updates a number of related tests.

In order to do that, we had to change the asserts and deprecations in
the transform so that when the `loc` information is not present no
errors are thrown.

The `{{collection}}` helper sets this automatically, so we need to
ensure the tests follow suit.

Some are still skipped, but will require further thought/details on
passing the renderer through to all children in
`ComponentNode.prototype.createOrUpdateComponent`.

Fixes JSHint error.

Note: that {{outlet}} templates without a view instance do not get a
default view any longer (the template is just rendered).

This is needed to target the parentView.controller with the action (when
it is provided in the template).

It is possible that in 2.x this conceptually needs to change from
`parentView.controller` to something else, but the general idea will
still remain.

Stream dependencies now mock the Stream interface which accomodates some
leaner code.

Stream now has a revalidate hook which is used for manual dependency
management. This hook is invoked in two cases:

  1. The stream just activated.
  2. The stream is already activate and is about to re-compute.

The commit ensures observers for a KeyStream are removed correctly.
A new revalidate hook was introduced as a place to clean up any manual
dependencies. This hook is invoked when the last subscriber is removed
(including when the stream is being destroyed).

Four new passing tests.

This commit modifies the AST transforms to match the Handlebars 3.0 AST.

And remove the workarounds from it being wrong.

Three more passing tests

I don't see a reason to bend over backwards to support the exact same
assertion language for this (deprecated) feature. This new message is
sufficiently clear.

42 tests green

As pointed out by @mitchlloyd in #10871.

Conflicts:
	packages/ember-routing-htmlbars/lib/helpers/render.js
	packages/ember-template-compiler/lib/plugins/transform-each-in-to-hash.js
	packages/ember-views/lib/attr_nodes/attr_node.js

This commit also adds several tests for the path and helper usages of
the subexpression form, e.g.

```hbs
{{capitalize (unbound  foo)}}
```

and

```hbs
{{capitalize (unbound if foo bar baz)}}
```

There are several paths and microsyntaxes for creating class name
bindings for a component’s element via Handlebars. For example:

`{{view ‘my-view’ class=“hello” classBindings=“:foo isApp:is-an-app”}}`

With HTMLbars, these have been deprecated in favor of a single API:

`{{view class=“hello foo (if isApp ‘is-an-app’)”}}`

This commit rewrites the AST of templates that contain the old syntax
into the new syntax at template compile time.

While it was a noble effort, the attempt to have ContainerView subclass
Component did not work because it broke propagation of the `controller`
template keyword.

Updates HTMLBars to ensure that initially undefined/null
`attributeBindings` are not set on the views element.

Fix class spacing for classNameBindings

The `{{component}}` keyword specifies `null` as `params` (since a
component cannot receive ordered arguments).  This commit simply adds a
guard to ensure we do not attempt to access `params.length` when
`params` is `null`.

this is all old implementation of pre-glimmer outlet behavior

isVisible fixes

…pers.

Context-changing helpers no longer allow an undefined context. Instead,
null is substituted for the context.

These tests were removed because they were only testing a stub renderer
defined in the tests.

MetamorphView (and the Metamorph mixin) are the final bastion of
virtual views. This commit removes much of their use.

MetamorphView had two behaviors: First, it was tagless. Second, it was
not included in the view hierarchy. The first concept (taglessness) is
still valid in Ember post-Glimmer. For this, we use `tagName: ''`.

The second concept (virtual views) is not longer present. So views which
previously used MetamorphView will not longer be able to escape the view
hierarchy. In most cases, the intent was likely to be tagless and being
virtual was simply a side effect.

OutletView and EachView will now be present in childViews and will be
parentViews.

`{{render` used to always create a view. Now, it will only create a view
if one is set by the user. By default it is only a componentNode and has
no view at all.

The final spot MetamorphViews are used it for the default itemView and
emptyView on EachView. This should be easy to address in a manner
similar to {{render: If the user does not specify a view, none should be
required.

After this, MetamorphView will no longer be used by internals.

Completely remove the concept of isVirtual

createElement requires that a view be rendered without the lifecycle
hooks being rendered. This leaves it in the hasElement state instead of
moving to inDOM as a normal render would.

this argument was used by the pre-glimmer OutletView only

This keeps us consistent with the DOM structure we produced
pre-glimmer. The topmost out ensures that it's child (not itself) always
has a real View with an element.

…ooner

Use templates instead of render method

- Rename render_test.js to view_test.js.
- Move conatiner view related tests to container_view_test.js.
- Remove invalid tests that are overly specific about rerender
  behaviour. There are much more comprehensive tests in view_lifecycle_test.js.

If a view is in a ‘preRender’ state (or any state for that matter)
attempting to destroy the element will effectively make any pending
view#append operations a noop.

The way `clearRender` works, it won’t call destroy on the top level
view if given `destroySelf` flag set to false. By moving the
`view.destroy` call into this hook, we can avoid destroying the top
level view when it is being cleared by `clearRender`.

The `view.lastResult` check seemed to just happen to work and needed to
be changed to get more tests passing.

Get more tests with view#remove working

It seems that this test was passing in spirit: the number of observers
does not increase when rerendering.

Interestingly, spaces are allowed when setting classNameBindings on a
view inside of a template.

{{view classNameBindings="prop:true:false anotherProp:more-true:more-false"}}

However, they are not allowed when setting the property on a view class:

Ember.View.create({
  classNameBindings: 'prop:true:false anotherProp:more-true:more-false'
});

To handle both of these cases, we split the incoming classNameBindings
property by spaces when using the view keyword.

View attribute fixes

Add back assertion for tagless components with classNameBindings

And a link-to test

Get remainder of query_params_test.js passing

… obvious

this.addDependency now assumes that the dependee is immutable. In
particular this means that it no longer returns the Dependency instance.
If you need access to the dependency you must now call
this.addMutableDependency.

This change allows this.addDependency to be a no-op if the passed in
object is not a stream. This is useful for subexpression streams to
avoid creating unnecessary dependencies for primitive values, as in
this example:

```hbs
{{concat values sep=','}}
```

 into idempotent-rerender

Just before a block is rendered, views are put into a renderedViews
list. When `rerender` is called, this list is checked to ensure the view
being rerendered has not already been rerendered.

These hooks are internal-only, not exposed publicly, and are only
intended to be used to emulate deprecated functionality for the moment.

Conflicts:
	packages/ember-views/lib/attr_nodes/legacy_bind.js
	packages/ember-views/lib/mixins/class_names_support.js
	packages/ember-views/lib/streams/should_display.js
	packages/ember-views/lib/views/collection_view.js
	packages/ember-views/lib/views/core_view.js
	packages/ember-views/lib/views/select.js

Idempotent rerender