Add lightweight witness/arbiter node support to MaxScale for 2-node quorum

Today, achieving safe automatic failover with mariadbmon cooperative locking requires a 3rd voting participant — but the only mechanism available is registering a full MariaDB server (real mariadbd, storage, replication stream) as a non-promotable monitored server.

MaxScale should support a native, dataless witness/arbiter/observer role that:

• Runs as a lightweight client process ( no storage, no replication, no mariadbd maybe?) — reports reachability of registered DB nodes to MaxScale for quorum calculation.
• Participates in cooperative_monitoring_locks majority math
• easy to configure: avoid using servers_no_promotion workarounds ?, since it's structurally never promotable. unless we want a dedicated new variable tracking these witnesses potentially
• Supports being deployed almost anywhere?, including on maxscale itself, including application-tier servers, so customers can achieve quorum without provisioning dedicated infrastructure
• Degrades gracefully if witnesses are unreachable, using that information as needed for calculations

Note:
critical for true AZ fault tolerance in 2-AZ deployments (a witness inside either existing AZ doesn't actually protect against that AZ failing outright).

Current Design

Implement a router for MaxScale that supports:

• GET_LOCK
• RELEASE_LOCK
• IS_FREE_LOCK
• IS_USED_LOCK
• RELEASE_ALL_LOCK

Additionally, support for SET statements must be partially supported so that wait_timeout is parsed and respected. The behavior should be exactly as in MariaDB.