Update guides section: Application Concerns

## Part One
Update the content for the Application Concerns section of the guides to reflect the following sub-sections (in the order listed). Note that these are improvements to the presentation, not changes to the content.

- [ ] "Injecting Dependencies": this would be a rework of the current "Factory Injections" section. It should lead with what is currently labeled "Ad-Hoc" injections. That label is bad because it makes it sounds like they're wrong, when really they are the best way to do it. It can then move on to type injections and instance injections, but making it clear that those are _advanced_ techniques typically used within addon libraries.
- [ ] "Looking Up Dependencies": this is the current "Factory Instance Lookups" section. There's no reason to hammer people with jargon like "factory instance", just stick to "dependency" throughout this page, the page is about _dependency_ injection.
- [ ] "Registering Dependencies": this would be a rework of the current "Factory Registrations" section. It should only presume knowledge of Initializers (which it can hyperlink to), and it should show all the examples _in the context of_ initializers. It does _not_ need to introduce the words "registry" or "owner" or "Application" or "ApplicationInstance". It can introduce the word "factory" to explain the difference between the default behavior and `instantiate: false`.
- [ ] "Understanding the Ember DI Architecture": this is where we'd put the highly abstract stuff defining "registry" and "owner". Even here I would drop attempts to define Application and ApplicationInstance. It's not central to the text, and you can hyperlink to their own API docs. We should also explain the real concrete reason that "registry" and "owner" are separate: you can share the registry across all users in FastBoot, whereas each user owns their own separate state (separate "owner").

## Part Two: Update Content for Octane
The content changes we need for Octane and native classes are:

- [ ] all uses of `extend` should become native class extend instead
- [ ] this implies teaching `inject` as a decorator
- [ ] the examples that use `@ember/component` would change to use `@glimmer/component`