fix(testing/time): fix FakeTime.restoreFor accuracy for sync callbacks

[Milly]

Fixed FakeTime.restoreFor to atomically restore and re-override globalThis.setTimeout etc.
This also fixes FakeTime.prototype.delay and FakeTime.prototype.runMicrotasks and others.

Of course, we don't get atomicity when an async function is specified to restoreFor.
However, FakeTime.prototype.delay that uses an non-async function will be fixed.

Example of runMicrotasks (that calls delay that calls restoreFor):

import { FakeTime } from "./testing/time.ts";

const testTarget = async() => {
   console.log(1, setTimeout);
   await Promise.resolve();
   console.log(2, setTimeout);
   await Promise.resolve();
   console.log(3, setTimeout);
};

const time = new FakeTime();
const promise = testTarget(); // no await, microtask is queued
time.runMicrotasks();
await promise; // already resolved
time.restore();

// Outputs before PR:
// 1 [Function: fakeSetTimeout]
// 2 [Function: setTimeout]
// 3 [Function: fakeSetTimeout]

// Outputs this PR:
// 1 [Function: fakeSetTimeout]
// 2 [Function: fakeSetTimeout]
// 3 [Function: fakeSetTimeout]

[CLAassistant]

All committers have signed the CLA.

[kt3k]

LGTM.

Wording of PR title might sound confusing, but this PR only changes the timing of overrideGlobals being called inside FakeTime.restoreFor when the given callback is sync. By this change, FakeTime.restoreFor works more accurately when the callback is sync, and that seems fixing the edge cases described in the above.

[Milly]

Additional fix pushed.
Reject instead of throw on TimeError.
Match the original behavior.

[kt3k]

Thanks. That makes more sense. Also thanks for updating the title