Moved adding of flags context into Scope

[antonpirker]

Using an error_processor to read data from the scope to add to the event is an anti-pattern. Moving this into Scope.apply_to_event().

This PR:

• moves code that adds flags to an event from an error processor into the Scope class
• moves add_feature_flag() function from sentry_sdk.integrations.feature_flags into sentry_sdk.feature_flags

This PR needs an update to this documentation PR: getsentry/sentry-docs#12300

[codecov]

Codecov Report

Attention: Patch coverage is 76.47059% with 4 lines in your changes missing coverage. Please review.

Project coverage is 80.16%. Comparing base (9f9ff34) to head (718dde6).
Report is 1 commits behind head on master.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
sentry_sdk/scope.py	72.72%	2 Missing and 1 partial ⚠️
sentry_sdk/feature_flags.py	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3917      +/-   ##
==========================================
- Coverage   80.19%   80.16%   -0.03%     
==========================================
  Files         140      139       -1     
  Lines       15412    15400      -12     
  Branches     2593     2596       +3     
==========================================
- Hits        12360    12346      -14     
- Misses       2207     2208       +1     
- Partials      845      846       +1     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/launchdarkly.py	78.37% <100.00%> (-1.11%)	⬇️
sentry_sdk/integrations/openfeature.py	72.00% <ø> (-3.00%)	⬇️
sentry_sdk/integrations/unleash.py	93.10% <ø> (-0.65%)	⬇️
sentry_sdk/feature_flags.py	80.00% <80.00%> (ø)
sentry_sdk/scope.py	85.15% <72.72%> (-0.36%)	⬇️

... and 3 files with indirect coverage changes

[antonpirker]

@cmanallen with this refactoring the FeatureFlagsIntegration is deleted, because it is not needed anymore. And add_feature_flag() would be living in sentry_sdk.feature_flags (instead of sentry_sdk.integrations.feature_flags).

I think this is a cleaner approach.
Is this is OK with you, or would that break users code or something? (I guess this would also be fine, because it is still in beta)

[cmanallen]

@antonpirker That integration hasn't made it to a release yet so no ones using it! Totally fine to remove it.