Create outfit member join/leave event about auraxium

[leonhard-s]

The background polling required to detect the member change requires a scheduled task, which would have to be part of the trigger itself.
This means that triggers must provide a hook to let events register scheduled tasks, which in turn means that the event must be able to register a task. This scheduled task would also need an input for the outfit ID to poll, which must be passed as part of the event definition.

All this combined makes me wonder if we should simplify Triggers to only handle subscriptions, task loops, and filters, with Events being responsible for defining subscriptions or scheduled tasks. This would also tidy up the redundancy of Trigger.conditions and the characters/worlds list in the Trigger initialiser; since the latter would be part of the Event definition (which is nice, since character IDs being available for FacilityControl events made no sense to begin with).

I am not sure if we can (or should) combine the Events passed to Triggers and the Events received by trigger actions into the same object.

[leonhard-s]

The following is an attempt to stick to a single Event object.

We cannot use the auraxium.Event initialiser to pass event-specific data; not without fighting pydantic over the initialiser. An alternative would be to use any variable-length positional arguments as inputs:

@client.trigger(auraxium.OutfitMemberJoin, 1234567890123456)
async def on_member_join(event: auraxium.OutfitMemberJoin) -> None:
    print(f'{event.member_name} joined on {event.membed_joined}')

We could even forward any arguments except for conditions= to the event, that way the current characters/worlds syntax would remain available for the built-in PS2 events:

@client.trigger(auraxium.Death, characters=[...], worlds=[...])
async def on_death(...):
    ...

The biggest difference would happen internally, since Events would need to expose a hook to register them, either by subscriptions or via scheduled tasks that can be attached to a given trigger.

[leonhard-s]

Putting this on hold until #34 is resolved.

[leonhard-s]

Closing as there is no real benefit to modelling this as a pseudo-event rather than a simple scheduled check.

Users wanting to check for outfit joins are advised to just store the list of members in a local file and run a checker at their desired schedule to scan for new members.