Use Rollup to build test suite

[tomdale]

Unlike the Glimmer VM monorepo, where packages are self-contained (i.e. they don't depend on any packages outside the monorepo), packages in Glimmer.js do have dependencies on external packages.

Ideally, we could:

1. Share duplicated dependencies when possible.
2. Allow packages to each have their own version of a dependency, if necessary.
3. (Unrelated, but I'm throwing it in here) It would be really great if we could run our tests against the production builds that people are actually using in Ember and Glimmer apps.

This pull request resolves all three of these issues.

1. It removes Lerna and switches to Yarn workspaces to give us automatic shared dependency hoisting and cross-package symlinking.
2. It replaces the unregenerate AMD build pipeline, piled with hacks and used only for testing, with a much simpler Rollup pipeline.
3. Like in real Glimmer.js apps, the production build artifacts are consumed by Rollup during testing so we can catch any errors here early.

At a high level, it works by generating a single entry point file that uses JS module syntax to import every test file in the system. That entry point file is passed to Rollup, which begins loading the test files.

Dependencies encountered while Rollup builds the bundle are handled in one of two ways:

1. A monorepo-resolver Rollup plugin will look at the importers path and, if originating from a file in a packages/ directory, delegates to rollup-plugin-node-resolve to resolve relative to that directory.
2. Another node-resolve Rollup plugin is configured to look up compiled Glimmer.js packages from a previous Broccoli transform.

Effectively, the lookup rules while building the tests are (relative to the project root):

1. ./packages/@glimmer/{pkg}/node_modules
2. ./node_modules
3. ./dist

In my tests, both bootstrapping the project, doing a build and running the tests are faster to varying degrees. More importantly, this change means that we don't have to worry about what happens if we ever have conflicting dependencies across two packages. It also means that debugging in tests is much easier since we don't have triplicate versions of every Glimmer VM package, only one of which is actually used.