DataCollection phase 1: resolver and SendDefaultPii bridge

Part of getsentry/sentry-dotnet#5420. Phase 1 — foundation.

Add the internal resolved config and the legacy bridge; make it the single read path.

* Internal `ResolvedDataCollection` (all fields populated), resolved once at SDK init and exposed internally (e.g. via `SentryOptions`).
* Resolution precedence: (1) fields explicitly set on `DataCollection`; (2) if `DataCollection` is set at all, missing fields use the new spec defaults (`UserInfo=true`, all `HttpBodies`, denyList behaviors, `FrameContextLines=5`); (3) if `DataCollection` is absent, derive everything from `SendDefaultPii`:
* `true` → everything on.
* `false`/unset → `UserInfo=false`, `HttpBodies=None`, `GenAI` off, `DatabaseQueryData=false`, deny-lists extended with GDPR terms (`forwarded`, `-ip`, `remote-`, `via`, `-user`).
* If both `DataCollection` and `SendDefaultPii` are set, `SendDefaultPii` is ignored.
* No consumer migrated yet — that happens per-area in Phase 2.

JS references: `resolveDataCollectionOptions.ts`, `defaultPiiToCollectionOptions.ts` ([getsentry/sentry-javascript#20967](), [getsentry/sentry-javascript#20970]()).

Locate DataCollection, SentryOptions, and the SDK initialization path, then read the referenced JS resolver files resolveDataCollectionOptions.ts and defaultPiiToCollectionOptions.ts for precedence and defaults. Done means an internally exposed ResolvedDataCollection is resolved once, the legacy bridge follows the stated SendDefaultPii rules, and no consumers are migrated yet.

Written by the indexing model from the issue text.