Fixes JAVA-596
Closes #5663

📜 Description

SentryTracer created a java.util.Timer (new Timer(true)) for every transaction configured with an idle or deadline timeout. new Timer(...) spawns a dedicated thread synchronously on the calling thread — often the main thread on Android — and each such transaction got its own throwaway thread.

This change schedules the idle/deadline timeouts on a dedicated, shared ISentryExecutorService instead:

• New SentryOptions.getTimerExecutorService() — a single SentryExecutorService created in activate(), kept separate from the main executor so timeout callbacks (which finish transactions) don't contend with cached-event sending.
• SentryTracer schedules cancellable Futures (idleTimeoutFuture / deadlineTimeoutFuture) on that executor. It does not cache a reference to the executor: it tracks a timersEnabled flag and looks the executor up from the options each time it schedules, so it always uses the instance currently held by the options (e.g. the fresh one installed after an SDK restart) rather than a stale reference. On finish only the futures are cancelled.
• Lifecycle: the timer executor is closed only on a full SDK shutdown (Scopes.close when not restarting). On restart it is intentionally left running so that pending idle/deadline timeouts of transactions started before the restart still fire and finish those transactions; the abandoned instance self-terminates once idle (allowCoreThreadTimeOut, 30s keep-alive).

💡 Motivation and Context

At scale (screen loads, HTTP spans, user-interaction transactions) the per-transaction Timer was the dominant source of SDK thread churn, and the thread creation happened on the caller's thread. This is item #4 ("Note B") of the thread/executor audit (JAVA-570 / SDK-1347) and is the biggest thread-count win in that effort. Using a dedicated executor (rather than the main one) keeps transaction-finishing work off the executor that sends cached events.

💚 How did you test it?

• Updated SentryTracerTest idle/deadline coverage to the new Future-based scheduling; the "timer executor shut down" cases now close the dedicated executor to exercise the immediate-finish fallback.
• Added ScopesTest coverage for the executor lifecycle: a full close shuts the timer executor down, while a restart leaves it running so in-flight timeouts still fire.
• ActivityLifecycleIntegrationTest idle-timeout test now installs a real timerExecutorService.
• Full :sentry:test and :sentry-android-core:testDebugUnitTest pass.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Follow-up audit items can fold the remaining per-Timer sites (DefaultCompositePerformanceCollector, RateLimiter, LifecycleWatcher) onto the same dedicated scheduler in a separate cleanup pass.