The use of `SocketAddr` instead of `IpAddr`

[CosminPerRam]

After the idea has been brought up after #41 has been merged: After I had a quick glance over the use of IpAddr, i wouldn't find using SocketAddr very clean, as SocketAddr::new requires an ip and a port, making queries where you do not know the server's port (want to try the default one) are ending up to be a bit confusing: Current way: query(address: &IpAddr, port: Option<u16>) which ends up to be used as:

• ah, I know the query port: query(&Ipv4Addr::new(127, 0, 0, 1), Some(25565)) versus query(SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 25565))
• ah, I do not know the query port and will leave the default one: query(&"127.0.0.1".parse().unwrap(), None) versus query(SocketAddr::new(IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)), 0)), where 0 might be the port number if the user does not know it and then it will be replaced with the game's default one?

However, this applies pretty much only to direct only-this-game queries, cause if you use the protocols, the port must be explicitly defined: pub fn query(address: &IpAddr, port: u16, ...), here I do find SocketAddr more cleaner.

[cainthebest]

Your concerns about the usage of SocketAddr when the port number is unknown or when you want to use the default port are valid. SocketAddr requires you to provide a port number when creating a new instance, which can be a bit confusing when you want to use a default port or when the port number is unknown, I oversaw this flaw. I think it can be done with a re-impl of SocketAddr with a Option<u16> type for port if it was necessary but I don't believe it is in this case of usage.