Allow overriding/configuring how SSM is installed on Ubuntu OS

What would you like to be added:
During nodeadm init it assumes that if you're running Ubuntu OS then you are managing the SSM daemon via snapd. This assumption is hard coded here.

Either the logic should be more robust to find/discover the systemd unit name through a list and filter/find approach or the user should be able to influence this logic at nodeadmin init runtime.

Why is this needed:
We aim for deterministic machine images and as a result, prefer to install all system dependencies during image build time rather than at runtime. The AWS SSM agent is installed on our Ubuntu images using dpkg/deb files and not snapd. The nodeadm install step handles this gracefully by skipping the installation of the SSM agent if it already exists on the system.

However, during runtime when the machine bootstrap runs nodeadm init, it assumes the SSM agent is installed via snapd and fails:

{"level":"info","ts":"2025-12-30T23:26:47.210Z","caller":"node/node.go:23","msg":"Setting up hybrid node provider..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"hybrid/validator.go:91","msg":"Validating configuration..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"flows/init.go:33","msg":"Configuring Aws..."}
{"level":"info","ts":"2025-12-30T23:26:47.213Z","caller":"ssm/config.go:44","msg":"Registering machine with SSM agent"}
{"level":"info","ts":"2025-12-30T23:26:47.691Z","caller":"ssm/config.go:66","msg":"Machine registered with SSM, assigning instance ID as node name","instanceID":"mi-XXXXXXXXXXXXXXX"}
{"level":"fatal","ts":"2025-12-30T23:26:47.693Z","caller":"nodeadm/main.go:57","msg":"Command failed","error":"configuring aws credentials with SSM: Unit file snap.amazon-ssm-agent.amazon-ssm-agent.service does not exist."}

The amazon-ssm-agent is however installed on the machine:

$ which amazon-ssm-agent                                                      
/usr/bin/amazon-ssm-agent

$ systemctl status amazon-ssm-agent.service
● amazon-ssm-agent.service - amazon-ssm-agent
     Loaded: loaded (/lib/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-12-30 23:27:59 UTC; 1h 17min ago
   Main PID: 10582 (amazon-ssm-agen)
      Tasks: 50 (limit: 629145)
     Memory: 57.7M
        CPU: 5.873s
     CGroup: /system.slice/amazon-ssm-agent.service
             ├─10582 /usr/bin/amazon-ssm-agent
             └─10604 /usr/bin/ssm-agent-worker

Read internal/ssm/daemon.go around lines 121-131, then trace the init path through flows/init.go and ssm/config.go. Reproduce the Ubuntu dpkg installation scenario shown in the issue and compare its amazon-ssm-agent.service unit with the snap unit. Done means nodeadm init handles the installed agent without the reported missing-unit failure.