Add sysctl with ipfw KBI version

[lytboris_gmail.com]

Summary

D54763 implements a workaround for ipfw KBI incompatibility introduced in D46183. It works fine for OS upgrades from 14.4 to 15.x but does not help with running an 14.4 jail with 15.0 kernel as jail initialization overwrites OS version with an older one.

This differential introduces a new sysctl node to detect ipfw KBI version reliably.

Compatibility detection in /sbin/ipfw should rely on it.

A new sysctl node is chosen to ease detection: no open() calls for socket are needed.

[vova_fbsd.ru]

The sysctl works, but I'd argue against introducing a new sysctl for this and suggest using the existing IP_FW3 sockopt interface instead.

Reasoning:

1. Consistency with the rest of the ipfw control plane. All ipfw configuration and introspection already goes through setsockopt(IP_FW3) / getsockopt(IP_FW3) — rules, tables, sets, skipto cache, etc. A KBI/version probe logically belongs to the same interface that the KBI itself describes.
2. The mechanism for version discovery already exists. IP_FW_DUMP_SOPTCODES enumerates the supported sopcodes together with their per-opcode IP_FW3_OPVER versions (see ctl_opcodes[] in ip_fw_sockopt.c). That is exactly what /sbin/ipfw needs to decide whether it is compatible with the running kernel — and it reflects reality more precisely than a single monolithic "KBI version" integer, because opcodes are versioned individually. If IP_FW_DUMP_SOPTCODES is not sufficient for the 14.4↔15.x case, it would be better to extend it (or add a dedicated IP_FW3 sopcode that returns a KBI marker) than to add a parallel discovery channel.
3. sysctl namespace hygiene. net.inet.ip.fw.* is user-visible and documented; a node that exists solely so that /sbin/ipfw can detect a kernel KBI quirk is implementation detail and doesn't belong in the user-facing sysctl MIB. It also has to be kept around effectively forever for ABI reasons once it ships.
4. Jails. The motivation in the summary is that jail init overwrites osreldate with the host-jail value. The sockopt path has no such problem and behaves identically in host and in jail, so it removes the whole class of "which knob gets overridden where" concerns — you probe the kernel you are actually talking to.

Minor nit on the patch itself: IP_FW_KBIVER=1500034 hard-codes a __FreeBSD_version-looking value. If this direction is kept, it should at least be tied to __FreeBSD_version in a comment so it is obvious when/why to bump it; otherwise it will silently rot.