refactor: move snap services to separate manager & monitor

[st3v3nmw]

Makes sure the extra services field doesn't trip up the server after the next landscape server release

[Perfect5th]

We need to be a bit careful here. Releasing this client version without backporting the fix to still-supported server versions will break those server versions.

I'd like to suggest a non-backward-breaking option instead: we use a different message type for snap services. Server automatically ignores message types it isn't aware of, and that way reporting installed snaps will still work even if reporting services doesn't.

The new message type can still be sent by SnapMonitor, or we could introduce a separate monitor/manager for services, which may give us flexibility if we find that we need service-specific reporting cadence or data handling.

[st3v3nmw]

I've refactored the code to introduce a separate manager and monitor set for snap services (SnapServicesManager & SnapServicesMonitor).

Also fixed the snaps message in SnapManager._send_snap_update to match the outgoing message schema. The list of snaps was being attached to snaps instead of snaps.installed. This also matches the behavior of SnapMonitor

Tested that reporting of installed snaps is working as before and that the new SnapServicesManager & SnapServicesMonitor are registered when the client starts.

[Perfect5th]

LGMT, thanks!

[Perfect5th]

Also tested against current version of landscape-server. Seems good.