Remove *all* preview types, update the publishing script to publish all
packages from source, and update the publishing tsconfig to include all
source packages.

**This *does not work* yet.** However, it is a necessary first step in
the process of switching to publishing stable types: the remaining
types are too deeply entangled with each other to publish them in
chunks as we have to date. (If there are exceptions, I have not found
them, and the overhead of finding them is higher than the cost of just
doing this switch-over.)

Previously, this was defined as a global in `ember-template-compiler`.
This was not really correct; it was a workaround for the way that the
`loader` package defines it as a global as a side effect of importing
and executing the module. Here, make it visible specifically *and only*
to the root `ember` package, where it is needed for defining the type
of the `Ember.__loader` object.

Some packages in the project supply `.d.ts` files which must be part of
both the authoring-time types *and* the published types, because they
represent values which become available at runtime by way of codegen.

For example, the `ember/version` module provides a `VERSION` value
derived from the package version. Both Ember's internals and the public
API include this value in various ways, but it does not have a
corresponding ES module on disk, so we provide a type definition
representing where it *notionally* lives, and that type definition must
also appear in the published types.

In these cases, simply copy the file from an input to an output
location, rather than trying to use `tsc` for them (since `tsc` will
actually ignore them).

`owner-ext` is a pass-through type definition module which adds the
`Registry` from `@ember/service` to the `DIRegistry` in `@ember/owner`
in a way that works for both internal usage within Ember *and* usage by
end users, given the constraints of our types publishing infrastructure
and its need to wrap all proper modules in `declare module { }` blocks.
Since this already *has* a `declare module { }` block, it does not need
to be wrapped; and since it is simply a `.d.ts` file, we can copy it
over rather than trying to emit it with `tsc` during build. (This is,
admittedly, a hack: but a sadly necessary one given our constraints!)

Instead of working around this in the type publishing infrastructure
(though we may ultimately want to do that as well), just *fix* it by
normalizing the import to the more "normal" form without `/index`.

We should, separately, fix that: it doesn't actually make sense for the
`RouterService` to be generic over a single route or even a set of
routes, so we need to go back and undo that type-level plumbing.

Use the full package name in both the broccoli build and all imports
which reference it, so that the types can resolve to them correctly.

This makes it so we can write code for things like the `DIRegistry`
which works correctly at both authoring and publishing time: it means
the side-effect-type modules can be in "module mode" rather than purely
ambient mode in both contexts. It also updates the definition of the
`@ember/service/owner-ext.d.ts` to be in module mode.

The previous test was overly generous, allowing users to pass anything
into the `buildInstance()` call and not checking that it worked with
the actual required arguments. This may technically be true, given how
the Ember APIs for `.create()` work under the hood (and that is how
this works, of course), but it's not *useful* to TS users, and it does
not actually represent the expected public API.

These can go through the normal pipeline by being a `.ts` files instead
of a `.d.ts` file in the source.

This makes `this.get('foo')` and friends work in roughly the same cases
where `get(this, 'foo')` and friends work.

The `Input` and `Textarea` components were previously being emitted as
the direct result of the `opaquify` item, with no name. This made it
impossible for TS to *automatically* emit them (a) with a useful import
name or (b) with a nameable type. Introducing an intermediate binding
and a type defined as the `typeof` the named constant, the combination
of which becomes the default export, maintains the existing runtime
behavior exactly while making the types name-able.

Use the same pattern for this as for extending the DIRegistry with the
service registry: create a passthrough copy of a module declaration
which is valid in both authoring and publishing contexts.

This prevents us from needing to emit (rewritten) relative paths for
the return type.

Services can be any object, both in practice for today and in a future
where Ember services don't have to have an Ember base class.

Introduce the ability to copy over hand-authored `.d.ts` files; Ember
has a number of these for things which exist at runtime but have no
corresponding authoring-time `.js`/`.ts` file, e.g. templates.

Along the way, make a couple significant improvements:

1. Switch to using the async versions of most operations, which mildly
   improves performance.
2. Extract some of the functionality into well-scoped functions to show
   the flow more clearly, and to handle the common process of writing
   an error to the console and bailing.

- `sortBy()` can accept multiple keys to sort on
- Type tests should not name `EmberArray` as `Array` lest they confuse
  the difference with global (real!) `Array`.
- Type tests should use public API imports, not private API imports.

Previously (i.e. on earlier versions of TS) we did not consistently get
the type params preserving the underlying types as robustly, but we can
now preserve this information.

Now that the service registry provides a constraint of `object` for the
entries, rather than no constraint whatsoever, we can update the tests
to verify this to prevent regression.

We can safely type *almost* all variants, but not using Ember's `bind`
with `this` and a string name. Introduce an appropriate fallback for
that case; this means that we cannot catch quite as many errors but in
exchange we get coverage over documented patterns in Ember's code.

(This gives us the same behavior as the preview and DT types always had
as a fallback.)

`namespace` and `module` both introduce TS `ModuleDeclaration` types,
so we distinguish between the two by checking whether it uses a string
literal (rather than an identifier) when excluding `declare module`
from the post-processing.

While the `namespace` construct is very much to be avoided for new
code, it is *exactly* correct for the case of the `Ember` namespace,
which is (precisely!) a namespace. To make this work:

- Combine the existing `const PartialEmber` and `const Ember` object
  bindings into a single `namespace Ember`.

- For the members assigned via `Object.defineProperty`, switch from an
  `interface` to `export declare let` and `export declare const`
  bindings on the `namespace`. Make sure to use `let` or `const` to
  match the readonly or writable semantics of the items defined thus.

Testing this exposed that at some point `Ember.run.later` and similar
nested namespace access stopped working, almost certainly at the point
when we dropped support for the namespace access from the module, but
our type tests still promised it. Noting that no *runtime* tests check
for this, remove the corresponding type tests.

This already works in the variant where the caller passes in an array,
but we did not have the overload for where they pass in multiple args.

Useful and *hopefully* accurate, but the implementation is a bit murky
as to what the intended semantics are, and the commit history is not
illuminating. This seems to capture the actual tested and documented
behavior accurately.

As with our service registry, we need these to live in separate files
so they can be copied over without change and so be able to perform
imports while *also* performing a module merge.

Since we have no ability to connect or check, within Ember itself or in
the things it provides to callers, the relationship between any given
Route model, Transition, and the overall RouterState, remove those type
parameters entirely in favor of just passing Ember's `Route` as the
type directly to `router.js`'s type parameters. This lets us simplify
the routing layer types considerably.

Also update a number of the type tests for the routing layer to match
Ember's actual behavior: the preview (and DT) types were simply wrong
at various points.

Add an overload which correctly handles keyof lookups.

- Give onerror a useful type (the one it has always had).
- Mark some exported items as private.
- Update the test suite to reflect the types from source: in some cases
  looser, in other cases somewhat tighter!

- Introduce `Column` type and use it as appropriate.
- Update type tests for the *actual* API: apparently DT had this wrong
  for many years.

- `deprecate` and `warn` can be called without args (this is not the
  intended behavior, but it is currently legal in the internals).
- `assert` needs to be typed correctly in the implementation to be
  `never` when no predicate is passed.

- Update prod `noop` bindings to cast away safety.
- Update type tests to expect `assert` to `asserts test` or be `never`.

TS helpfully tries to infer a mutually-compatible type when passed more
than one object in an array (to allow narrowing etc.), but with QPs on
a Controller, we actually do *not* want that behavior; so when passing
both `type` and a rename in the same QPs config, use `as const`.

Although this is a build-time-only API, which is ultimately removed
from the distributed build, it is perfectly legal for Ember users to
*name*, especially if doing their own build tooling work; as such, it
needs to provide the types it has when used in the build.

Without this, some TS-generated `import()` types naming a given item
where the runtime code simply relies on inference get emitted without
the top-level `@ember/` namespace. This special case makes sure we do
not drop that: if we ever find it, we know we *need* to emit it.

- Correctly capture deprecation options.
- Flag CP syntax we do not expect to work.
- Make `@sort` less type-safe, to match `Array.prototype.sort`.

This fixes many of the incompatibilities from our type tests, and makes
the resulting code *much* clearer at the same time. The key here is to
move away from trying to use tuple spread types to just constraining
the actual args and mapping their types into a `Pick` or `Record`.

`Component` uses `ViewSupport`, but `ViewSupport` defined its `this` as
`Component`. This was a classic form of cycle which blocked supporting
the `Mixin`-based programming model effectively with TS in the first
place and was a major motivator for investing in native classes back in
the early Ember 3.x days! here, the fix is to use `this: CoreView`
instead so that `ViewSupport` does not need to name `Component`, only
the chunk of `Component`'s base types it actually uses.

As a bonus, remove a needless `extends FrameworkObject` from the merge
on the interface of the `CoreView` class, since normal inheritance does
correctly preserve that.

As described in the RFC, we do not want to attempt to provide the type-
modifying capabilities of these functions. The result is type safe but
not especially useful, but that is as we want: using `create` to
provide values not on the base type *or* to change its values is quite
undesirable; and using `reopen` and `reopenClass` to dynamically update
instance and static members of a class has serious (and not obvious!)
performance downsides and discoverability problems for maintainers, and
will ultimately be deprecated entirely as part of removing Classic.

A key result is that `.create()` now allows *any* props to be set, but
does not update the resulting type. This is an unfortunate necessity
given how Ember *itself* uses `.create()`.

Ember's own types are now less generous about `evented`'s `addListener`
and `removeListener` functions than the preview/DT types were, because
Ember's implementation has been simplified and the types had not been
updated to match.

Again, this already correctly `extends CoreObject` because the class
itself does so; we only need to merge in declarations with mixins.

While people should generally move away from this and to native `Proxy`
this makes it possible for existing code to be well-typed.

Account for both the improved `Proxy` type safety and the removed
`CoreObject.create` type safety in the type tests.

These referred respectively to imports which existed only in DT/preview
types and a removed API!

This gets us a *small* amount of type safety, rather than absolutely
none: it does not check the types passed into `.create()` match, but
since there is little reason to directly call this for end user code
(vs. for internal code, which actually uses this dynamic capability!),
this gives us the actual runtime behavior: if you smash a property with
a new type, you... do.

Even though we have an "opaque" class here, we still need to make sure
both the static type of the class and its runtime type are available
to callers to name.

This matches the runtime behavior. We do not catch setting things this
way, as a result, but in a world where native property access works
everywhere, this is actually somewhat useful: it means you can set
anything on a target object, and although the type will not be updated
with that change, it will at least type check in a way that matches the
dynamic runtime behavior.

This was useful to prevent us from regression in the DT/preview types
era, but these are covered by Ember's internals being required to type
check as part of CI now, and we have also simplified or removed most of
this machinery.

The resulting types are just records, where `Pick` preserves some extra
info because of the dynamic class behavior.

The fact that `Ember.get` gets very confused on deeply mapped types
combined with `this` types is not surprising, but is also not relevant
to a test where no one *should* use `get()` instead of normal property
access.

As with the earlier commit removing some of this, we have no ability to
check these types, so they are just extraneous overhead.

Now that `create` can catch this, it lets us know about our own lies.

- Re-export the relevant types from `@glimmer/interfaces` as well as
  wiring them up to the appropriate points in the exported functions.
- Add the hooks necessary to make the exported `on` modifier visible to
  Glint, including adding an `Opaque` internal type.

- Provide the correct type for the first param for the callback passed
  to `registerHelper()`.
- Add a cast and an explanation for type test on `TestAdapter`

Without this, neither `.extend()`ing `Component` nor the documented
`reopenClass` pattern works with `positionalParams`.

- Make `templateOnlyComponent` and associated types usable with Glint
  the same way the preview types were.
- Fix the way we name the types of `setComponentTemplate` in tests. In
  the real world, the way to get the type is via calling another public
  API; here we just want to make sure the function *requires* the
  correct thing.

- Do not emit `| () => never` for functions in `@ember/test`: while it
  is true that those *will* error if `ember-testing` is not included,
  the underlying function type is still correct even there, since the
  immediately-throwing handler is a legitimate function subtype of the
  expected behavior when the library *is* included. Additionally, that
  inclusion is normally a build-time concern.

- Apply some formatting tweaks to the definition of `registerWaiter`'s
  implementation definition and `prettier-ignore` those lines to make
  it more legible.

- Update a `register` call in a type test to use a proper 'full:name'.

Provide the same public API as the preview types. This requires lying a
bit about the return type of `helper()` in particular, but no part of
Ember's own internals cares about the details: they are relevant *only*
as the point where they are actually created. The provided type avoids
a number of possible kinds of errors by providing an opaque item which
cannot be constructed but which *does* preserve generics. Moreover, the
actual details of type returned by `helper()` are *not* public API, so
this correctly avoids exposing those details.

As a bonus, remove a number of extra internal type aliases on both the
source and that were used in the preview types.

- Do not expose Glimmer's private/internal notion of a template-only
  component, even for type tests.
- Do provide the full *call* API for Glimmer's `templateOnly()`.

This syntax is namespace-specific: `import` in a namespace is aliasing
one namespace to another, while `export` marks the item public on the
namespace (as with the rest of the exported items).

At the moment, some *tests* pass no resolver, and expect this to work
anyway. The fix is to have those tests pass a test-friendly resolver
and then this will work as expected.

Supporting the TS `namespace` export for the `Ember` namespace object
(in 2fdb3f5) required aliasing many of the imports; one of these was
hidden by having a `@ts-expect-error` on that statement for unrelated
reasons.

The existence of the `_Backburner` re-export is of a private item, and
this test simply checks that the re-export works as expected; sinc we
updated the build pipeline not to do the weird renaming shenanigans it
did previously to make `'backburner'` the import downstream, we can
update this test to match the actual Node-resolveable location as well
(see 80b738d for background).

`@ember/test-helpers` uses these as they exist in the DT and preview
types, so to avoid breaking that, re-supply them here. They should not
be relied upon long-term, but this allows us to migrate the library's
dependency chain distinctly from the release of these types.

Co-authored-by: Dan Freeman <dfreeman@salsify.com>

There are three categories of `.d.ts` files we manually copy over as
part of our publishing process:

- `*-ext.d.ts` modules, which supply module merge declarations manually
  to allow the regular module to go through the normal postprocessing
  chain while still allowing the imports to work correctly for the
  declaration merge. These must be copied over and left exactly as they
  are, no post-processing.

- Modules which correctly represent a runtime-only location of an API,
  which appear at one point in the source graph, but must be emitted at
  a completely different location for runtime/import. These must be
  copied over and left as they are, no post-processing, but targeting a
  different location to emit them.

- Modules which must be copied over and then post-processed, because
  they represent runtime-only code which must be importable as a normal
  module via a relative path *and* must be wrapped in `declare module`
  to be usable in the emitted types.

Separate those pieces of functionality, extract a module-scope list for
the latter two, and rename the local functions accordingly.

Instead of `typeof`, export `interface` types which can be merged with
by Glint, and which are kept distinct from each other with the `Opaque`
utility type, while preserving `OpaqueInternalComponentConstructor`.

This does not affect type checking, but since theses items will now be
exposed to consumers, at least explicitly signal via their docs (seen
on hover etc.) that they should not be used.

Co-authored-by: Dan Freeman <dfreeman@salsify.com>

Co-authored-by: Dan Freeman <dfreeman@salsify.com>

Without these, anyone using them directly as a type will get a type
error reporting that they are missing.

This type test will let us know if we change that behavior, rather than
indicating that it is the *desired* behavior.