making SW_WATCHDOG dynamic

[Mike Karels]

My proposed change is in Phabricator, https://reviews.freebsd.org/D13713.

A couple of notes:

- I retained the SW_WATCHDOG option; it now just enables the software
watchdog even if a hardware watchdog is attached, as it would have done
in the past.  I updated NOTES and the watchdog(4) information accordingly.
I did not provide for any other combination of watchdogs or actions; that
would require a complete rework of the kernel API.  Note that the hardware
watchdogs provide no choice of action; they simply reset the box.

- I have tested this with and without the SW_WATCHDOG option, but do not
have a hardware watchdog to test with.  If someone could test this, it would
be much apprectiated.  I tested by enabling watchdogd with default parameters,
doing b"killall -STOP watchdogd", and then observing that the system dropped
into the debugger after about 128 sec.  It drops into the debugger if KDB
is defined and KDB_UNATTENDED is not; otherise it panics (as before).

I neglected to respond this this from Andriy Gapon:
> P.S.
> And maybe just using the second software watchdog would be good enough for what
> you are doing?

I think the hardclock-based SW_WATCHDOG is better than the --softtimeout
wactchdog because it runs at a lower level (hardclock vs callout/softclock).
In particular, I have found it to work in situations where a locking
deadly embrace started in the network stack, and then a callout routine
got stuck as well when a function it called blocked on the offending lock.
That caused watchdogd to fail to be rescheduled, and the watchdog fired as
a result.  The callout-based facility could have been blocked out as well.

		Mike