Adjust test to pass with slower GHA macOS box

[mceachen]

This should allow the upgrade to 3.43 to pass:

Failure from GHA:

  1) new Database()
       should accept the "timeout" option:
     AssertionError: expected 1468 to be close to 1000 +/- 200
      at testTimeout (test/10.database.open.js:101:31)
      at Context.<anonymous> (test/10.database.open.js:109:3)
      at process.processImmediate (node:internal/timers:476:21)

https://github.com/WiseLibs/better-sqlite3/actions/runs/5965363532/job/16186656443?pr=1050

[mceachen]

@JoshuaWise this is blocking the upgrade to SQLite 3.43.

[Prinzhorn]

I find this offensively worse to read tbh 😄

[mceachen]

Yeah, the first time I saw specs written like this, I found it a bit off, as well! Tabular specs have grown on me, though, to the point where I strongly prefer them. It allows you to DRY up your spec, ensures the same operation is being performed with all the different inputs, and most importantly, highlights the input and expected results.

One of the assertions was failing, and I wanted to add the JSON context to it. One solution would be to extract 7 new it's with specific test names, but Josh doesn't follow the one-test-one-spec rule--so I wanted to add the timeout description to the context, but that caused every expectation to linewrap, which was really effective in hiding what the tests were doing.

[mceachen]

(That said, if @JoshuaWise would rather me rewrite this diff, I don't really care--I just want the PR to go through)

[JoshuaWise]

Closing this in favor of 6ee3399. This is also related to #597. I've enabled the long-overdue HAVE_USLEEP=1 compile-time option, which allows the timeout option to be more granular. It turns out that when enabling HAVE_USLEEP=1, the CLI builds for macos-latest take much longer than expected. After investigating, the test times were always 2x-3x the specified timeout. For example, if the timeout was 200ms, it would take 400-600ms; if the timeout was 1000ms, it would take 2000-3000ms. The behavior is quite mysterious, but I can't reproduce it on my local MacOS machine, so I assume it could have something to do with GitHub Actions de-prioritizing virtual machines that are idle. Anyways, it works as intended on all real machines I test it on, so I don't think it's a big deal. In any case, timeouts are never exact in programming—they are always best-effort/minimum times anyways.