* ESLint no-default-exports part 4

* Fix default imports

* Fix default imports

* Fix manager Modals import

* Release notes

* ESLint no default exports - part 3

* Fix default imports

* Release notes

* Fix Menu

* ESLint no default imports - Button

* Fix

* Release notes

* Fix Button imports

* ESLint no-default-imports part 1

* Release notes

* Remove Notes.tsx default export

* Fix Notes imports

* Enable prefer-const project-wide

* Release notes

* Fix remaining lint errors

* Another round of prefer-const rule updates

* Release notes

* Fix test error

* Fix sync.ts

* ESLint prefer-const components folder part 2

* Release notes

* ESLint prefer-const components folder part 1

* Release notes

* Part 2 of eslint prefer-const

* Release notes

* Update

* Break apart budget/misc.js

* Release notes

* Rename release notes

* UI bolder "No server" text

*  (eslint) add 'plugin:react/recommended'

* Release notes

This is to prevent any further color changes added to PRs. This will
help prevent the darkTheme getting any addition work loaded onto it.

I noticed that:

- The web and electron versions of our `uuid` module both looked exactly
the same…
- …and deferred to the `uuid` package…
- …and the async version just called the sync API.

So now we will just use the `uuid` package directly everywhere.

This cleans up all of the usage of `<a>` in the codebase. Now all
external links get the appropriate attributes added.

This significantly speeds up `yarn lint` for me. It also ensures we’re
listing all source files in the project, including the `.eslintrc` files
and any other files that may be present.

- New linter rules are now added
- Perhaps the `createPayee` method i've tagged with a disable should be
deleted.
- I have ignored unused methods in Plaid/Mobile as this stuff is still
WIP/experimental?

Bundle sizes are unchanged but now we no longer pull in the
Electron-specific FS code on the web version

- Enforce that imports from the same package are merged into a single
import
- In `loot-core`, require that imports of other `loot-core` files use a
relative import (like the vast majority of such imports) rather than
specifiers starting with `loot-core/` (probably a result of moving files
out of other packages into `loot-core`)

Multi-line `if`/`for` statements in JS can be confusing since there
aren’t braces to indicate which code is enclosed in the statement. I set
the configuration to `multi-line` to enforce usage of braces for
multi-line statement bodies, but still allow things like `if (foo)
return;`. I additionally added the `consistent` option to require braces
for all elements of an if/else chain if one element has it. As you can
see, this set of options pretty closely matches the existing code style.

I was going to comment in #1008 about this stylistic change but realized
that it’s (IMO) a little impolite to ask for code style changes unless
they can be automatically enforced.

Note that `if (foo) { \n return; \n }` is still valid and won’t be
collapsed. I tried to automatically collapse all such cases but it was a
lot of files and I didn’t want to pick out the useful from the useless
differences.

Switch to TS version of `no-unused-vars` rule.