Update README to reflect latest state

[machty]

This should hopefully make it more clear to newcomers how this addon is used and why it's named the way it is.

1. Clarify the intent of this addon to implement First-Class Component Templates
2. Remove references to old template literal syntax
3. Link to Road to Stability issue

[chriskrycho]

We appreciate the PR! I'd like to actually keep the level of changes here much smaller, though, at least initially. In particular, I'm onboard with adding some of the new material linking it to the merged RFC, but I would prefer we keep around the existing contents for folks using both <template> and hbs—the latter is still supported. Also, the examples had some good material in them!

[chriskrycho]

This addon implements the [First-Class Component Templates
RFC](https://rfcs.emberjs.com/id/0779-first-class-component-templates/), which
introduces `<template>` tags as a format for making component templates
first-class participants in JavaScript and TypeScript with [strict
mode](https://rfcs.emberjs.com/id/0496-handlebars-strict-mode/) template
semantics.

It also serves as a home for other syntaxes built on the same underlying primitives in Ember, including using `hbs` tagged template literal strings to create templates in JS. Although these are not the ultimate design for First-Class Component Templates, they remain supported for the transition period.

[chriskrycho]

Let's not hard-wrap, please!

Suggested change

	First-class component templates address a number of pain points in today’s component
	authoring world, and provide a number of new capabilities to Ember and Glimmer users:
	- accessing local JavaScript values with no ceremony and no backing class, enabling much
	easier use of existing JavaScript ecosystem tools, including especially styling
	libraries—standard [CSS Modules](https://github.com/css-modules/css-modules)
	will “just work,” for example
	- authoring more than one component in a single file, where colocation makes sense—and
	thereby providing more control over a component’s public API
	- likewise authoring locally-scoped helpers, modifiers, and other JavaScript functionality
	Here is an example of a `.gjs` / `.gts` component file, which demonstrates how other
	components (e.g. `MyComponent`) can be imported using JS/TS `import` syntax, and then
	rendered within the embedded `<template>` tag:
	First-class component templates address a number of pain points in today’s component authoring world, and provide a number of new capabilities to Ember and Glimmer users:
	- accessing local JavaScript values with no ceremony and no backing class, enabling much easier use of existing JavaScript ecosystem tools, including especially styling libraries—standard [CSS Modules](https://github.com/css-modules/css-modules) will “just work,” for example
	- authoring more than one component in a single file, where colocation makes sense—and thereby providing more control over a component’s public API
	- likewise authoring locally-scoped helpers, modifiers, and other JavaScript functionality
	Here is an example of a `.gjs` / `.gts` component file, which demonstrates how other components (e.g. `MyComponent`) can be imported using JS/TS `import` syntax, and then rendered within the embedded `<template>` tag:

[chriskrycho]

I'm fine with removing this particular section, but let's leave the sections after it.

[chriskrycho]

Closing in favor of #169. Thanks again for doing an initial pass here!