User assigned values for `CrashedLastRun`, `EnableScopeSync` and `ScopeObserver` are ignored

[jamescrosswell]

Originally posted by @jamescrosswell in #4521 (comment)

CrashedLastRun, EnableScopeSync and ScopeObserver get overwritten when initialising the Native, iOS and Android integrations... e.g.

sentry-dotnet/src/Sentry/Platforms/Cocoa/SentrySdk.cs

Lines 154 to 158 in cc613c9

	// Set options for the managed SDK that depend on the Cocoa SDK. (The user will not be able to modify these.)
	options.AddEventProcessor(new CocoaEventProcessor());
	options.CrashedLastRun = () => SentryCocoaSdk.CrashedLastRun;
	options.EnableScopeSync = true;
	options.ScopeObserver = new CocoaScopeObserver(options);

sentry-dotnet/src/Sentry/Platforms/Android/SentrySdk.cs

Lines 177 to 179 in aab708f

	options.CrashedLastRun = () => JavaSdk.Sentry.IsCrashedLastRun()?.BooleanValue() is true;
	options.EnableScopeSync = true;
	options.ScopeObserver = new AndroidScopeObserver(options);

Any user configured values for these will get overwritten/ignored.

If that's what we want, those options should probably be internal (not public).

Alternatively we should respect the value that the user assigns to EnableScopeSync and chain/wrap the CrashedLastRun and ScopeObserver delegates so that both the user's code and ours get executed.

[linear]

NET-449 Should CrashedLastRun, `EnableScopeSync` and `ScopeObserver` be internal?

[Flash0ver]

We are thinking about removing SentryOptions.EnableScopeSync from the public API surface area,
and instead have it implicitly enabled by user code setting a SentryOptions.ScopeObserver,
or our Native/Android/iOS implementations setting a respective platform IScopeObserver,
or an aggregate of both a User and Sentry IScopeObserver.