perf(core): Lazily allocate AutoClosableReentrantLock (JAVA-588) (#5643)

* perf(core): Lazily allocate AutoClosableReentrantLock (JAVA-588)

AutoClosableReentrantLock extended ReentrantLock, so every SDK object
holding one allocated a ReentrantLock (and its AbstractQueuedSynchronizer)
eagerly in its field initializer. A customer Perfetto trace showed ~81 such
allocations on the main thread during SentryAndroid.init, many for locks
that are never acquired during init.

Hold the ReentrantLock internally and create it lazily on first acquire(),
using an AtomicReferenceFieldUpdater CAS so creation stays atomic and
Loom-friendly (no synchronized, preserving #3715). Every call site uses
acquire() only, so dropping the ReentrantLock superclass touches no caller.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* changelog

* perf(core): Harden lazy lock init and mark AutoClosableReentrantLock internal (JAVA-588)

Replace the unreachable candidate fallback after a failed CAS with an
explicit non-null check, so a broken invariant fails loudly instead of
handing two threads different locks. Mark the class @ApiStatus.Internal
and make the lazy-allocation test assert the lock field directly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* perf(core): Return the lock itself as the lifecycle token (JAVA-588)

Every acquire() allocated a fresh lifecycle token, which is per-use
garbage on every lock acquisition forever, not just at init. The token
was stateless apart from its lock reference, so AutoClosableReentrantLock
now implements ISentryLifecycleToken itself and acquire() returns this,
making the steady-state acquire/close path allocation-free. Semantics
are unchanged: try-with-resources closes once per acquire, so reentrant
acquires stay balanced, and unlocking without holding the lock still
throws IllegalMonitorStateException.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>