chore: Add tracking for feature flags

[denrase]

#skip-changelog

📜 Description

Track runtime use of the manual feature flag APIs by adding featureFlags to sdk.features after the API is used.

Runtime-discovered features are stored internally and thread-safely on the active SDK options, then merged with the existing option-derived features when SDK metadata is built.

💡 Motivation and Context

We want internal telemetry showing actual feature flag API adoption, matching the behavior in sentry-flutter. Inferring this at SDK initialization is not possible because feature flags are enabled through runtime API usage.

Closes #8594

💚 How did you test it?

• Added tests for feature storage, deduplication, ordering, concurrency, SDK
  metadata generation, and the SDK/Hub feature flag entry points.
• Manually used Add Scope Flag in the iOS Swift sample, captured an event,
  and confirmed featureFlags appears in the event's sdk.features JSON.
• Link to Sentry:
  https://sentry-sdks.sentry.io/issues/6607086585/events/latest/?project=5428557&query=is%3Aunresolved&referrer=latest-event

📝 Checklist

• 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.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.
• If I added a new public API, I also added it to the SentryObjC wrapper.

[sentry]

📲 Install Builds

iOS

🔗 App Name	App ID	Version	Configuration
SDK-Size	io.sentry.sample.SDK-Size	9.24.0 (1)	Release

⚙️ sentry-cocoa Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1227.21 ms	1260.16 ms	32.95 ms
Size	24.14 KiB	1.27 MiB	1.24 MiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
f0c60b7	1224.60 ms	1259.33 ms	34.74 ms
8469478	1240.30 ms	1277.07 ms	36.76 ms
3ba6174	1222.29 ms	1265.35 ms	43.06 ms
91f06a6	1213.64 ms	1259.58 ms	45.93 ms
b6fa517	1218.83 ms	1257.47 ms	38.63 ms
31e3b65	1225.70 ms	1246.98 ms	21.28 ms
00009c7	1231.69 ms	1265.73 ms	34.04 ms
952f116	1221.55 ms	1248.72 ms	27.17 ms
e3070ad	1240.00 ms	1274.43 ms	34.43 ms
07d6099	1224.06 ms	1247.13 ms	23.06 ms

App size

Revision	Plain	With Sentry	Diff
f0c60b7	24.14 KiB	1.22 MiB	1.20 MiB
8469478	24.14 KiB	1.24 MiB	1.21 MiB
3ba6174	24.14 KiB	1.25 MiB	1.23 MiB
91f06a6	24.14 KiB	1.24 MiB	1.21 MiB
b6fa517	24.14 KiB	1.14 MiB	1.12 MiB
31e3b65	24.14 KiB	1.23 MiB	1.21 MiB
00009c7	24.14 KiB	1.24 MiB	1.21 MiB
952f116	24.14 KiB	1.24 MiB	1.21 MiB
e3070ad	24.14 KiB	1.16 MiB	1.14 MiB
07d6099	24.14 KiB	1.17 MiB	1.15 MiB

[itaybre]

This seems a bit over engineered, at this moment I believe a simple boolean flag would be simpler and if we end up with other features like this we can build the set logic

[denrase]

@itaybre Thought I add something generic as we track multiple runtime values in flutter and it's easy to query this data, but we can also do it simpy and then expand if needed.