Improve tracker API contract

[defagos]

As a developer integrating Pillarbox I want custom tracker implementation to be easy to understand and achieve. Currently this is not the case from a Pillarbox developer point of view, at least looking at our comScore and Commanders Act implementations.

Context

Our current tracker implementations subscribe to various sources with subtle dependencies and slightly misaligned published values (see #559). After #559 has been investigated and hopefully implemented, we might be able to provide a better contract for custom tracker implementation.

Some ideas:

• Maybe the context published in Publish consolidated item context #559, if this can be achieved, could be the source of truth for trackers. Maybe it should be publicly accessible with a dedicated API (computed properties) to extract valuable consistent state.
• Maybe CurrentItemTracker could observe these changes and call another tracker protocol API method to notify trackers about essential changes. This could avoid implementations all having to perform the same kind of necessary subscription when the tracker is enabled.
• Maybe objectWillChange (or did change if we add a run loop delay) could provide this change stream instead. Implementations would then access the player to get everything they need after a change.

Acceptance criteria

• Tracker implementations are simple and do not require complex subscriptions to various sources.

Tasks

• Implement the above strategies to find if one works.

[defagos]

Can likely be closed after #607 has been implemented.

[defagos]

The retained approach is to expand the PlayerItemTracker protocol with methods called when metadata or player properties are updated. This eliminates the need for apps to implement publisher subscriptions in their tracker implementation.

The objectWillChange idea was not required / implemented.