- Rename the existing `build` command to `build:js`, introduce a
  `build:types` command, and make a new top-level `build` command that
  dispatches both of the others with `npm-run-all`.

- Update handling for type checking to include separate passes for the
  library TS code and *each* of the type test packages.

We might want *some* lints on these at some point, but for now this is
the right tradeoff here.

- The modules needed to be "absolute" not "relative" for the filtering
  to work correctly.
- That in turn meant we needed to *insert* a relative lookup.
- But we also needed to make sure we treat top-level packages *as such*
  rather than linking to their `index`, else TS does not resolve them
  correctly with these side effect modules.

- Remove `@ember/-internals/owner` and `@ember/owner` from the list of
  excluded preview types in the types publishing script, so they now
  get emitted correctly into `types/stable`.

- Remove `@ember/owner` from the preview types and put it in the stable
  types instead, so users don't get conflicting type dependencies.

- Internally in `@ember/owner`, use absolute package paths, not
  relative. For referencing other (even internal) packages, it's
  important that we *not* use relative paths, so that (a) the published
  types work when wrapped in `declare module` statements but also (b)
  we have clearer boundaries for them, which will unlock further
  improvements to this infrastructure in the future.

These really belong in the `@ember/application` re-export, not in the
tests for `@ember/owner` itself, which should have no knowledge of the
existence of `@ember/application` (but vice versa is fine).

This guarantees that we will be testing exactly what our consumers use,
with the only difference being the specific import paths used to expose
the side effect modules. It also keeps the type tests from diverging
between the two sets of types.

Previously, following the DefinitelyTyped approach, all the preview
type modules had their own `tsconfig.json`, but this actually made them
fail to interoperate with stable types, and this approach *only* works
if they work together. Removing those means they operate as a single
coherent set of type definitions with the stable types, distinguished
*only* by the way they are authored.