Introduce new entity to store one to many information (e.g. posts, follows, etc)

This issue is to refactor the internal storage. If two users follow the same users, posts will be duplicated. Let's fix that!

This introduces the ActivityPubTimelineItem entity which stores relations between activities and actors so we can easily build timelines for users!

Current fields on that entity:

• aid: entity reference to an activity
• uid: owner of this relation
• relation: (string) type of relation. Doesn't store 'Type' (Create, Like etc), although they more or less match at this point (current values: create, reply, dm, like, announce, follower)
• actor: the actor of the activity (up for debate to drop, currently used to quickly set all items to muted from an actor you mute in the Reader implementation)
• is_read: whether you read the activity (dropped from the activitypub entity)
• is_muted: whether this post should show up in your home timeline (you follow the actor, but you want to temporarily ignore their posts - 'mute' is still on the activity table for the main 'Follow' activity)

This is not 100% written in stone, see thoughts down below.

Use cases:

• Post item: for 1 'Create' activity from an actor followed by multiple users. The activity is only created once, but every user who follows that actor gets a (post) relation. Important note: we already skip creating 'duplicate' activities when they arrive in the inbox, so we needed something to get around this issue anyway!
• Multiple item types: create, like, announce, follow, reply, dm and follower. This allows for faster queries to generate timelines whether it's for the reader module, or soon for the API endpoints. At this point the timelines for the reader module start from the activity table. That should switch probably, which will happen in #3573057: Create dedicated methods on the activity storage for specific calls (tests currently work, but they are not ideal in every place)
• Every timeline item has following fields: is_muted, is_read. E.g. if user A mutes an actor, every relation from this actor for that user will be muted, while user B can still see the posts in their home timeline. Same for the 'read' property.
• This will be useful when the shared inbox is added in #3572268: Add a shared inbox
• Further fields can be added here in the future.

Remaining work/thoughts:

• This has impact on views and access, but that will be fixed in #3573056: Refactor views integration

This issue when committed is not 100% written in stone, follow-ups can be created if needed.

Side effects of this patch: full PHP 8.4 support, and activity entity is already fieldable.