This PR adds client-side support for int8 aka bigint.
Supporting BigInts is tricky because of inconsistencies in the sqlite
drivers.
For example, better-sqlite3 requires BigInts to be explicitly enabled
but then *all* integers are returned as BigInts because SQLite does not
distinguish between them (they are all just 64bit integers). On the
other hand, wa-sqlite returns a regular JS number if the integer fits,
otherwise it returns a BigInt.

To avoid these problems, we always cast BigInt to text when reading from
the DB and then let the DAL turn it into a BigInt;
i.e., when the Postgres type of a column "foo" is bigint, we read as
follows: `SELECT cast(foo as TEXT) AS foo FROM table`. Similarly, we
cast returned values: `INSERT INTO table VALUES (9223372036854775807)
RETURNING cast(foo as TEXT) AS foo`.

A similar problem occurs in the oplog triggers. These triggers insert an
oplog entry for every insert/update/delete. This oplog entry contains
the old and new rows as JSON objects. However, JSON does not support
BigInts:
```sql
sqlite> SELECT json_valid('{"a": 123n}');
0
```
We also can't write it as a regular number because when parsing the JSON
it is read as a number and rounding errors occur:
```js
js> JSON.parse('{"a": 9223372036854775807}')
{ a: 9223372036854776000 }
```

Hence, the triggers also need to cast BigInts to text and the
deserialisation function for oplog entries (`deserialiseRow`) needs to
correctly deserialise them as BigInts (when the column type is
int8/bigint).

---------

Co-authored-by: David Martos <[email protected]>