Add support for SNAT randomization exclusion ranges

[ethan-gallant]

What would you like to be added:
The ability to use randomized SNAT but exclude specific port ranges from randomization.

Why is this needed:
Randomized SNAT is extremely useful in multi-tenant workloads like Kubernetes. It greatly enhances the stability of the network and prevents traffic from being dropped should two pods send an outbound request from the same port.
However several protocols such as Bittorrent and other P2P protocols that rely on predictable NAT behavior will fail with fully randomized SNAT. Specifically, the following protocols are incompatible with --randomize-fully:

• STUN (Session Traversal Utilities for NAT) - Used for NAT traversal and network discovery
• ICE (Interactive Connectivity Establishment) - Critical for WebRTC and other real-time communications
• UDP hole punching protocols - Used by many P2P applications and games
• SIP with direct media - Used for VoIP and video conferencing
• BitTorrent and other P2P file sharing protocols - Require predictable port mapping
• WebRTC in peer-to-peer mode - Used for browser-based real-time communication
• Cryptocurrency wallet P2P discovery - Many blockchain nodes use NAT traversal for peer discovery and connection

The ability to exclude specific port ranges from randomization would allow us to maintain the benefits of randomized SNAT for general traffic while preserving compatibility with these protocols in designated port ranges.
Would you like me to add any additional sections to the issue template, such as potential implementation approaches or specific use cases?