[kernel,net] Convert WD driver to TH/BH intr regime and fully buffered

[Mellvik]

Converts the WD/SMC Ethernet driver to the new TH/BH interrupt structure - and to the fully buffered regime previously added til the ne2k driver. Tested on 8216 and 8416 NICs on two different hardware systems. The speed is just slightly lower than the previous 'direct' version on an otherwise idle system, and probably higher than before on a loaded system.

The driver uses the same netbufs= directive as the ne2k driver. The default # of buffers is 2+2.

[Mellvik]

The second commit of this driver update was supposed to be just cleanups and adjustments, but turned into something else.

1. A race condition was discovered in the 'interaction' between write() (filling buffers) and putpacket (empty buffers) which, if the number of transmit buffers was 3 or more, would mess up the sequence and cause transfer to stop - until traffic on a different connection kicked it back into life. The first fix was to use interrupt protection, which - being undesirable - was replaced by separating the transmit-next and fill-next (head and tail really) buffer pointers.
2. Confusing the issue, a (assumed) different race condition was discovered, initially thought to also be at the driver level, then at the application (ftp) or socket level, then ktcp, finally narrowed down to a MacOS bug. Unbelievable: MacOS 26.3 TCP does not timeout and retransmit when the client twice acks a previous sequence number. It just sits there. It took two days of testing (and lots of hardware mixes and matches in search for a more likely culprit) to reluctantly come to that conclusion. Lost packets happen, in particular when old hardware is involved. Like, the ne1k (or ne2k in 8 bit mode) interface will always experience occasional RX errors under heavy load, which in most cases mean lost packets. There good news is that with MacOS 26.4.1 the problem is gone. Whether it was a transient - something accidental in a recent version - or something that has been around for a while, I don't know.
3. The above situations were discovered on one of 3 running test systems, and (hours later) deemed non-repeatable on the other systems. Which doesn't make fixing less important, but made the development-environment unbearable: 3 systems, 4 different WD/SMC NICs and IRQ settings that needed to be different between systems, requiring DOS and EZSETUP countless times. To alleviate the problem, the second commit includes NIC IRQ autoconfiguration from the setting in /bootopts. A dramatic practical simplification and one that has been pending for a while. In this commit, the addition is optional (conditional compile) — to be removed in a forthcoming cleanup.