Tighten is_iprange()

As written, the function doesn't detect the incorrect malformed range where 2 IPs are of different types. So it will incorrectly validate malformed user input such as 1.1.1.1-::8000 (or any mix of IPv4 to/from IPv6) as "valid" IP ranges.

Also - and this probably isn't a useful feature - a range should be (low ip)-(high ip). But is_iprange() doesn't test this, so it validates "ranges" with ip1>ip2, such as 255.255.255.255-128.0.0.0 (is this the range union ff.ff.ff.ff UNION 0.0.0.0-80.0.0.0, or are the args the wrong way round?) There is no valid case where IPs should be in this order, and if the IPs are reverse order it shouldn't validate, this would be very strange, may cause other functions to fail (if they expect IPs in the usual order), and is very unlikely to be deliberate intended input.

The rewrite fixes these.

NOTE: - is_ipaddr() and is_iprange() returned a True/False value. As any positive number will Boolean-evaluate to True, I have taken advantage of this to have "success" usefully return 4 or 6 (not just "true") to say the type of ip or range matched. It's no extra effort or cost, transparent to any Boolean test, and allows a lot of efficiency and code simplification elsewhere, since calling code that needs to validate an IP or IP range, and find if it's IPv4 or IPv6, a common situation, can now do this reliably with one is_ipaddr() or is_iprange() call. Example use:

if (($res = is_ipaddr($data)) {
 if ($res == 4) {
 Immediately enter IPv4 handler code...
 } else {
 Immediately enter IPv6 handler code...
 }
 } else
 Invalid data, enter error handler code...