chore: add support to set screen name to all event

[thisames]

💡 Motivation and Context

#119

💚 How did you test it?

The tests have been updated to include checks for the new $screen_name property in any event.
I tested it manually and analyse the props in dashboard.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

[marandaneto]

I think this approach leaves room for too many false positives.
eg I call screen(x) for screen X, but I don't call screen(y) for screen Y, when events are captured in the screen y, the screen name is x.

[marandaneto]

I think a better approach would be using https://github.com/PostHog/posthog-android/blob/main/posthog-android/src/main/java/com/posthog/android/internal/PostHogActivityLifecycleCallbackIntegration.kt
So we can cache the current Activity based on the screen's lifecycle and infer the name from it.
If screen is called either manually, it has precedence over the current activity.

[thisames]

I see, you are correct. The problem with using PostHogActivityLifecycleCallbackIntegration.kt is that we would have to add method signature in PostHogInterface, and i dont know if it make sense.

see theses changes
thisames@7d4a6f5

do you think this make sense?

[marandaneto]

I think we should add a new concept to the SDK that allows enriching the event after being captured, for example, an event processor.
I will make an example and you can expand from there

[marandaneto]

See this example https://github.com/PostHog/posthog-android/compare/chore/processors?expand=1

[thisames]

Thank you, you made it much easier for me. I will update this PR with the changes and then you check and give me the ok, if it works I will do the unit tests

[marandaneto]

Another option is to use the super properties for the screen name

posthog-android/posthog/src/main/java/com/posthog/PostHog.kt

Lines 783 to 802 in 3a0ede8

	public override fun register(
	key: String,
	value: Any,
	) {
	if (!isEnabled()) {
	return
	}
	if (ALL_INTERNAL_KEYS.contains(key)) {
	config?.logger?.log("Key: $key is reserved for internal use.")
	return
	}
	getPreferences().setValue(key, value)
	}
	public override fun unregister(key: String) {
	if (!isEnabled()) {
	return
	}
	getPreferences().remove(key)
	}

both would work the same

[thisames]

I prefer the solution with processors, it's working well

[thisames]

@marandaneto ready for review