Add all advanced options to rule table hover text

Bug #3512
firewall_virtual_ip , allow deleting last ip-alias if interface uses same the subnet. (while CARP-ip is present)
Update services.inc

Added missing usepublicip with dyndnsCheckIP
Fix for now 'IPv6 - LAN looses Prefix after link event'(forums) with a not elegant solution but works. Probably dhcpv6 client should solve this by itself and generate and event for it. For now just bump dhcpv6 client again to have the prefix interface reconfigured.
Merge pull request #1003 from phil-davis/patch-2

Add all advanced options to rule table hover text
Fix OpenVPN XML section name

Forum https://forum.pfsense.org/index.php?topic=73479.0
Merge pull request #1015 from phil-davis/patch-4

Fix OpenVPN XML section name
Fix order of parameters to explode() here
Update services.inc
Update services.inc

Prepared to make $hosttocheck configureable
Merge pull request #1012 from florian-asche/patch-1

Update services.inc
Update services.inc

IPv4 ONLY
Update services.inc

Added CURL setops from dyndns.class
Update dyndns.class

IPv4 ONLY? YEAH ;)
Merge pull request #1019 from florian-asche/patch-4

Update dyndns.class
Do not delete linklocal address
Merge pull request #1018 from florian-asche/patch-3

Update services.inc
Merge pull request #1010 from PiBa-NL/alias_allow_delete

firewall_virtual_ip , allow deleting last ip-alias if interface uses same the subnet. (while CARP-ip is present)
Make this a bit more efficient
Validate rule Advanced Options numeric entries

This makes sure the user puts in ordinary positive integers like "1" and "42" in these advanced options fields. It prevents everything else, including dodgy-looking possibilities like "007" which might actually work OK, but it is safer to allow just plain "7".
Note 1: The tests in function is_aoadv_used($rule_config) had to be changed back from using empty() to use $var != "" because if the user enters "0" in one of those fields and presses save, they get an error message, but the Advanced Options block on the GUI is closed (the "0" was considered empty()). That seemed rather confusing - the user would have had to click on the Advanced Options "Advanced" button again to open up that block and see the "0" they had entered.
Note 2: I have prohibited 2 things that "pf" allows into the ruleset without generating an error:
(max 0)
(tcp.established 0)
Both of these seem (IMHO) to have no valid use case. They would prevent states from ever happening, and so would effectively be block rules, which could be implemented easily as block rules.