Another batch of `loot-core` migrated.

Co-authored-by: Jed Fox <git@jedfox.com>

Another batch of files from `loot-core` migrated to TS (loose mode)

This PR converts everything (aside from electron) from CommonJS to ESM.
It is needed to reduce the changes that will happen during the migration
to Typescript (as TS does not play nice with CJS).

Basically:
- rewrite `require()` to `import`
- rewrite `module.exports` to `exports`
- introduce `ts-node` to run importers so we can convert them to TS too

Lastly, sorry for this larg-ish PR, not my preference but when I tried
to reduce its scope, I would end up with mixed commons/esm that was even
more tricky to handle.

Fixes #840 by creating application-defined SQL functions
(https://www.sqlite.org/appfunc.html) for Unicode-aware implementations
of `LOWER()` and `UPPER()`. This uses
`String.prototype.toLower/UpperCase()` JS method.

I initially wanted to just redefine `LOWER()` and `UPPER()` but due to
[sql.js not supporting the definition of deterministic
functions](https://github.com/sql-js/sql.js/issues/551), I had to just
define them as separate functions and use that in the appropriate
places. It's probably better like that anyway...

Route aggregate queries in transaction grouped mode through the correct layer to remove deleted transactions (#247)

I recently migrated my personal usage of Actual over to the open-source
version and imported a bunch of transactions. I have a _lot_ of history
in Actual, including a lot of weird edge cases like deleted split
transactions. While reconciling I noticed that my account balance shown
at the top was incorrect, even though the running balance was current.

Digging into this, I discovered that we aren't correctly handling
aggregate queries when querying transactions in the "grouped" mode.
Aggregate queries don't make sense in the "grouped" mode. Grouped means
that you want a list of transactions that include both the parent and
child transactions (when they are split). If you are summing up all the
amount, you only want to consider non-parent transactions. So we switch
it back to "inline" mode, but the way we did this previously was to
manually stitch the query together.

Even though was add SQL to ignore deleted transactions, we still
possibly include them. A child transaction may not be marked as deleted,
even though the parent transaction is deleted. When a parent transaction
is deleted, all child transactions should be considered deleted as well,
regardless of their tombstone status. This is what the
`v_transactions_internal_alive` view does. Previously we weren't going
through this view though, so we could still potentially include split
transactions even though they've been deleted.

This is little hacky, but it fixes the immediate problem. We fall back
to the inline mode by modifying the where clause, and we also adjust the
view that it queries to use the correct one.

*  (prettier) adding trailing commas

* More commas

*   upgrade eslint-plugin-import and fix issues

* Change import ordering

* style: enforce sorting of imports

* style: alphabetize imports

* style: merge duplicated imports

* style: enforce ordering of imports

* style: sort imports in loot-core

* style: sort imports in desktop-client

* style: sort imports in loot-design

* style: manual fixes