feat: Add OptionConfiguration to replace Runtime/BuildTime

[bitsandfoxes]

Fixes #1621

Based on the issue description: The aim is to have users no longer need to know or care about Runtime and BuildTime differences. They write their code in once place, we use the same options at any time.

Platform specifics can be controlled via the Unity precompile directives. We include a sample of those with the generated template:

using Sentry;
using Sentry.Unity;

public class SentryConfiguration : SentryOptionsConfiguration
{
    public override void Configure(SentryUnityOptions options)
    {
        // Here you can programmatically modify the Sentry option properties used for the SDK's initialization

#if UNITY_ANDROID || UNITY_IOS || UNITY_STANDALONE_OSX
        // NOTE!
        // On Android, iOS, and macOS, ALL options configured here will be "baked" into the exported project
        // during the build process.
        // Changes to the options at runtime will not affect the native SDKs (Java, C/C++, Objective-C)
        // and only apply to the C# layer.

        // Examples:

        // Works as expected and will disable all debug logging of the native SDKs
        // options.Debug = false;

        // Will NOT work as expected as this will need to get validated at runtime
        // options.Debug = SystemInfo.deviceName.Contains("Pixel");
#endif
    }
}

The Runtime/BuildTime config got deprecated but will still be called last as keep backwards compatibility. I've updated the config window with a warning label that shows as long as there are either Runtime or BuildTime configs.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against dbf1dbf

[vaind]

The Runtime/BuildTime config got deprecated but will still be called last as keep backwards compatibility. I've updated the config window with a warning label.

What do you think about only showing the new option on the UI by default and only show the original options (i.e. as in the screenshot), when any of the original options are actually set in the existing config?

[vaind]

It would be simpler but we would lose on the ability to catch native exceptions happening at startup. Is that worth it?

[bitsandfoxes]

What do you think about only showing the new option on the UI by default and only show the original options (i.e. as in the screenshot), when any of the original options are actually set in the existing config?

After giving it a try I think that's fair. I've updated the window logic.