Refactor activity center count fetching

[jrainville]

Description

Currently, in the activity center view, we call the module, which in turn calls the controller, the service and then status-go, each time the QML code wants to know the count.

See here:

status-desktop/src/app/modules/main/activity_center/view.nim

Lines 54 to 56 in 95d8db2

	proc unreadActivityCenterNotificationsCount*(self: View): int {.slot.} =
	self.unreadCount = self.delegate.unreadActivityCenterNotificationsCount()
	return self.unreadCount

This is doubled with the fact that the service call is sync:

status-desktop/src/app_service/service/activity_center/service.nim

Lines 172 to 179 in 95d8db2

	proc getActivityCenterNotificationsCounters(self: Service, activityTypes: seq[int], readType: ActivityCenterReadType): Table[int, int] =
	try:
	let response = backend.activityCenterNotificationsCount(
	backend.ActivityCenterCountRequest(
	activityTypes: activityTypes,
	readType: readType.int,
	)
	)

We should refactor this code so that status-go is only called when needed.
We should also make it so that it's async.

So the view should have a copy of the count and serve only that to the QML.

When we have potential updates, we call the async call to check the count and then update the view with the new count.

Or even better, have status-go be the emitter at all times (except the first app load). Meaning that when the count of status-go is updated but external or user events, there is a response or signal from status-go that includes the count currently.
However, the difficulty with this option is that we would then need to save the current AC setting in status-go (All, Mentions, Replies, etc.)

Do note that the count of unread AC notifs is also used in the main module to see if we have notification to show the red dot:

status-desktop/src/app/modules/main/module.nim

Lines 967 to 968 in 95d8db2

	method onActivityNotificationsUpdated[T](self: Module[T]) =
	self.checkIfWeHaveNotifications()

[jrainville]

Moving this 2.31 as I just realized, that just like the wakuext_getLatestVerificationRequestFrom, this gets called WAY too much
app_20240819_132019.log