GeezerVison

<ng-container>, <ng-template>, and <ng-content> don't render an
element, so Angular ignores class, style, attribute, and event bindings
on them, and every binding on <ng-content>. These templates compile and
run without a word, although the bindings never take effect.

Add NG8031 (`ignoredBinding`), a type-check diagnostic that
reports these bindings and static attributes. It needs strictTemplates,
is a warning by default, and is configured through
`extendedDiagnostics.checks` like NG8011. It doesn't report:

- bindings that a directive input or output claims;
- directive host bindings, since a directive is reusable;
- static attributes when a directive or a structural directive matched
  the element, a content projection slot selects it, or Angular reads
  the attribute;
- global event targets such as `document:` and `window:`.

Add NG0319, a dev-mode runtime error that logs class, style, and event
bindings on <ng-container> and <ng-template>, so JIT is covered too.

Add NG8032, a template type-check warning for a component whose
selector matches <ng-container> or <ng-template>. Neither can host a
component: dev mode throws an assertion, and production mode throws a
DOM error when it attaches the component's view to a comment node.
It's a warning for now, because a template that never renders the
element, for example behind an `@if` that is always false, runs today.

The language service no longer suggests DOM attributes on
<ng-container>.

Also report `[attr.x]` on an <ng-container> inside <svg>. The parse
check missed it there, so the binding failed later with a misleading
assertion in dev mode. Templates that hit the new parse error never
worked.

Also fix `<ng-content selector="h1">` in the upgrade examples, which
meant `select`. NG8031 found it, and the repo's build fails on
warnings.

Don't report a property or event binding whose name appears in the
selector of a directive that matched by that selector. Directive
matching uses these binding names, so the binding makes the directive
match even when no input or output claims it, as in
`<ng-template [foobar]>` with a `[foobar]` selector and no input.
Host directives aren't matched by their selector, so their selectors
don't count.

Also add tests for `[class]` and class interpolation on <ng-container>,
an event binding on <ng-template>, a static class that a projection
slot selects, and <ng-template> inside <svg> and inside a namespaced
element.

Move the three selectorless NG8031 tests from the intentional ngp
differences to the known ngp failures, in their own group. They fail
on ngp with NG2024, because ngp doesn't resolve selectorless
dependencies yet.

Report a component whose selector matches <ng-container> or
<ng-template> as an error. Neither element can host a component, so
the template fails when it renders: dev mode throws an assertion, and
production mode throws a DOM error.

BREAKING CHANGE: A component on <ng-container> or <ng-template> is
now an error

A component whose selector matches <ng-container> or <ng-template>
now fails to compile with NG8032. Such a template already failed when
it rendered. Use an element that matches the component's selector
instead.