sg: Support managing rules for arbitrary port/IP combinations

[ivyleavedtoadflax]

Problem

The security group commands are heavily oriented around SSH (port 22). While add-ip, remove-ip, and list-ips accept a --port flag, the broader workflow makes it cumbersome to manage rules for other services:

1. SSH-centric naming and defaults — helper functions are named get_ssh_ip_rules, clear_ssh_rules, etc., and whitelist_ip_for_instance only operates on a single port.
2. One port at a time — to open access for a service like Syncthing (which needs ports 8384 and 22000), you must run remote sg add-ip twice with separate --port flags.
3. No service presets — common multi-port services require the user to remember the exact port numbers each time.
4. --whitelist-ip on connect is SSH-only — remote instance connect --whitelist-ip only adds a rule for port 22, with no way to also open other ports needed for the session.

Proposed Improvements

1. Multi-port support in a single command

Allow specifying multiple ports in one invocation:

remote sg add-ip my-instance --port 22 --port 8384 --port 22000

2. Named service presets

Provide built-in presets for common services:

remote sg add-ip my-instance --service syncthing   # Opens 8384 (GUI) + 22000 (sync)
remote sg add-ip my-instance --service ssh          # Opens 22
remote sg add-ip my-instance --service http         # Opens 80 + 443

Presets could be defined in config or as built-in defaults.

3. Port ranges

Support port range syntax for services that need contiguous ranges:

remote sg add-ip my-instance --port 8000-8100

4. List all rules (not just one port)

remote sg list-ips currently filters to a single port. Add an --all flag to show rules across all ports:

remote sg list-ips my-instance --all

Implementation Notes

• The low-level functions (add_ip_to_security_group, remove_ip_from_security_group) already accept a port parameter, so the core AWS interaction is ready
• The main changes are in the CLI layer and helper functions to support multi-port workflows
• Rename SSH-specific helpers (e.g., get_ssh_ip_rules → get_ip_rules) to reflect general-purpose use
• Consider extending --whitelist-ip on connect to accept a --service or additional ports