Completed work:

* Copy a few modules to `packages/`
* Upgrade Yarn to v3
* Add Yarn workspaces
* Add Yarn constraints for `package.json` in root and package
* Reconfigure TypeScript support new structure
* Reconfigure Jest to support new structure

Remaining work:

* TypeDoc — it doesn't seem to support TypeScript project references, so
  we may have to generate docs for each package individually or figure
  out something else
* ESLint — the `node` and `import` plugins are tripping up on imports
  which are aliases — we either need to disable the appropriate rules or
  get the plugins to recognize `tsconfig.json` appropriately

The package manager used has been upgraded from Yarn v1 to Yarn v3. All
of the steps in the migration guide [1] have been followed. Effectively
everything should work the same way it did before.

Closes #847

[1]: https://yarnpkg.com/getting-started/migration

The old `setup` script has been replaced with a Yarn v3 plugin that
will automatically run `allow-scripts` after install. We can now use
`yarn install` again as normal.

This was done to address a problem that happened when running
`yarn setup` for the first time. If Yarn 3 wasn't installed already, it
would throw an error. Yarn 3 doesn't automatically install itself until
you run the `install` command directly.

The `setup` script has been left behind for now so that it still works
if people run it accidentally. We can remove it later once we've become
accustomed to this new workflow.

Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>

Other changes:

* Remove overrides in `.eslintrc` for import/*` rules
* gitignore `*.tsbuildinfo` files
* Fix file name of `constraints.pro` so it actually takes effect
* Get `yarn lint` working

* Fix tests
* Replace isomorphic-fetch with cross-fetch (cross-fetch has better
  TypeScript types, and working with a non-global is generally a better
  experience)
* Upgrade @ethereumjs/tx and @ethereumjs/common (for some reason the
  Common type wasn't the same between the two packages)
* Move asset-related utils from controller-utils to assets-controllers

Confirm that all dependencies are synchronized using the same version
and that no dependencies are listed multiple times in the same
`package.json`.

* AddressBookController and PreferencesController from user-controllers
* EnsController and PhishingController from third-party-controllers

…kages

Some of our dependencies use ESM and need transpiling in order to use
properly. We previously solved this by creating a special
`tsconfig.json` file for tests where we turned on `allowJs: true`, and
then using the `ts-jest/presets/js-with-ts` Jest preset as well.

We don't need to do this, however, because we can specify
`customExportConditions` instead, which will tell Jest that when it is
resolving imports to ignore `browser` entries in `exports` and choose
`cjs` instead.

We can't start at 0.0.0 because this repo already has tags, so
`create-release-branch` will fail to run because there's no v0.0.0 tag.
So the monorepo will start at the currently release version of
`@metamask/controllers`.

…ery is added

…s, fix more issues

Co-authored-by: Mark Stacey <markjstacey@gmail.com>

…r envs

In Node, `setTimeout` returns NodeJS.Timer, whereas in the browser,
`setTimeout` returns a number. So we if assign a type of NodeJS.Timer to
the variable here (see diff), `tsserver` will be cool with it, `tsc`
will be cool with it, but Jest will not be cool with it (because we've
instructed the `transaction-controller` tests to run within a jsdom
environment, and so `@types/node` [somehow] does not apply in this
case).

Also ensure that when we use the Jest `jsdom` environment we clear out
the existing options we'd set for the `node` environment, just so we
know that Jest isn't trying to do something we don't expect it to.

Co-authored-by: Mark Stacey <markjstacey@gmail.com>

…JSDocs

* origin/main:
  Use cached dependencies and immutable install during publish (#942)
  Add clear function for NotificationController (#943)
  Bump actions (#944)