fix(timers): order timers with the Java MessageQueue instead of ALooper fds

Timers were delivered through a pipe fd registered with ALooper_addFd.
Android services fd callbacks inside MessageQueue.nativePollOnce at every
message boundary, so timer callbacks and Handler messages lived in two
queues with no mutual ordering: a setTimeout(0) could fire before or
interleave around an already-queued Handler.postDelayed(0) runnable.

Timers now ride the Java MessageQueue itself via a dedicated per-runtime
TimerHandler bound to the isolate's Looper:

- Each scheduled timer enqueues one message with sendMessageAtTime, so
  timers share a single queue with Handler.post/postDelayed and fire in
  exact MessageQueue order.
- Messages are anonymous "due tokens": a native list sorted by exact
  (sub-millisecond) due time picks the earliest due timer per token,
  preserving the previous relative ordering of JS timers despite the
  millisecond-quantized Java queue.
- Due-now timers post at (long)now so they tie (FIFO) with a
  postDelayed(0) made in the same millisecond; future timers post at
  ceil(dueTime) so they never fire early.
- The background watcher thread, pipe, mutex and condition variables are
  removed; the MessageQueue does all delayed scheduling and everything
  runs on the isolate's thread with no locking. Worker isolates get the
  same behavior on their own loopers.

Also adds ordering regression tests (timers vs Handler posts), scheduled
from a java-posted runnable to avoid the >=5-level nesting clamp that
jasmine's spec chaining otherwise triggers.

Fixes timer/Handler ordering so setTimeout(0) reliably yields behind
already-queued main-thread work.

Author: edusperoni

test-app/app/src/main/assets/app/tests/testNativeTimers.js

@@ -94,6 +94,49 @@ describe('native timer', () => {
             done();
         });
     });
+    // these specs schedule from a java-posted runnable so they run outside any
+    // timer callback: jasmine chains specs through timer callbacks, and when
+    // the runtime is built with NS_TIMERS_NESTING_CLAMP the nesting clamp
+    // (>=5 levels -> 4ms minimum) would otherwise make setTimeout(0)
+    // legitimately lose to a postDelayed(0)
+    it('preserves order with java handler posts', (done) => {
+        const order = [];
+        const handler = new android.os.Handler(android.os.Looper.myLooper());
+        handler.post(new java.lang.Runnable({
+            run: () => {
+                setTimeout(() => order.push(1));
+                handler.postDelayed(new java.lang.Runnable({ run: () => order.push(2) }), 0);
+                setTimeout(() => order.push(3));
+                setTimeout(() => {
+                    expect(order.join(',')).toBe('1,2,3');
+                    done();
+                }, 100);
+            }
+        }));
+    });
+
+    it('interleaves many timers with a java handler post', (done) => {
+        const order = [];
+        const handler = new android.os.Handler(android.os.Looper.myLooper());
+        handler.post(new java.lang.Runnable({
+            run: () => {
+                for (let i = 0; i < 50; i++) {
+                    setTimeout(() => order.push('t'));
+                }
+                handler.postDelayed(new java.lang.Runnable({ run: () => order.push('j') }), 0);
+                for (let i = 0; i < 50; i++) {
+                    setTimeout(() => order.push('t'));
+                }
+                setTimeout(() => {
+                    // the java runnable must land exactly between the two timer batches
+                    expect(order.indexOf('j')).toBe(50);
+                    expect(order.length).toBe(101);
+                    done();
+                }, 100);
+            }
+        }));
+    });
+
     it('frees up resources after complete', (done) => {
         let timeout = 0;
         let interval = 0;