Lazy-allocate SentryOptions sub-options objects

[runningcode]

Problem

Every SentryOptions eagerly constructs SentryReplayOptions, SentryFeedbackOptions, ExperimentalOptions, logs/metrics sub-options, ClientReportRecorder, etc. (field initializers + ctor in sentry/src/main/java/io/sentry/SentryOptions.java). This is paid even by throwaway instances:

• the static globalScope uses SentryOptions.empty() (Sentry.java:68),
• SentryPerformanceProvider builds a full options object just to deserialize the app-start profiling config (sentry-android-core/.../SentryPerformanceProvider.java:122).

Proposal

Investigate lazy holders for sub-options (allocate on first getter access). Manifest parsing touches several of them during init, so the win materializes mainly for secondary options instances and disabled features — measure the allocation delta with an ART allocation trace before committing.

Constraints

• Getters are called from multiple threads post-init; lazy init must be thread-safe without adding per-call lock overhead (e.g. double-checked volatile, or the existing LazyEvaluator — but note Reduce AutoClosableReentrantLock allocation churn during init #5642/Reduce per-instance lock overhead in SentryId and SpanId #5644 reduced per-instance lock churn; don't reintroduce it).

[linear-code]

JAVA-621