Option to split Linux Memory check into individual services (RAM, Swap, Committed)

I would like to propose a new discovery feature for the native Linux memory check (mem_linux) that allows administrators to optionally split memory monitoring into three distinct services: Memory RAM, Memory Swap, and Memory Committed.

Currently, Checkmk bundles these into a single unified service. While this works well for a high-level view, it introduces critical limitations for enterprise alerting workflows.

The Problem: Alert Blindness
When RAM, Swap, and Committed memory are bundled into a single service, any single component crossing a threshold locks the entire service into a WARN or CRIT state. If a secondary, more severe event occurs on a different component, no new notification is triggered.

Example Scenario:
1. Committed Memory hits its threshold > Service goes CRIT (Alert notification sent).
2. Used RAM subsequently hits its critical threshold while Committed Memory is still high > Service remains CRIT.
Because the overall service state never transitioned (it stayed CRIT), the monitoring team is left entirely blind to the fact that physical RAM is now also exhausted.

Proposed Solution
Instead of replacing the existing check, introduce a configuration toggle within the Memory and swap usage on Linux WATO rule.
Default behavior: Keep the current unified single service.
Optional behavior: A checkbox/switch to "Split into individual services". When enabled, service discovery would create separate services for each memory attribute.

Why This Benefits the Community
Eliminates Alert Blindness: Allows teams to configure independent alerting pipelines, escalation chains, and notifications for physical vs. virtual memory exhaustion.
Granular Thresholds: Cleaner management of distinct warning/critical thresholds per component.
Zero Disruption: Because it is an opt-in discovery feature, it will not disrupt or change the service counts for customers who prefer the unified view.