panic()/KERNEL_PANICKED(): Move back to using 'panicstr' as a flag

Currently, no performance-critical path tests for a panic. Moreover, we
today have KERNEL_PANICKED() which wraps the test into
__predict_false(), already catering to those (potential) use cases.
Also, in practice we don't support 64-bit architectures without caches,
so reading an 'int' instead of a pointer doesn't (directly) save any
memory access. Finally, 'panicked' is redundant with 'panicstr' (and
wastes a tiny amount of memory).

Consequently:

1. Use again 'panicstr' as a flag indicating that the system is

panicking. To this end:

1. • Modify panic() so that it ensures this pointer is set to some non-NULL value even if the caller didn't pass any panic string.
   • Modify KERNEL_PANICKED() to test for 'panicstr'.
   • Remove 'panicked'.
2. Annotate 'panicstr' with '__read_mostly' (instead of using

'__read_frequently' as for 'panicked'). This may have to be changed if,
in the future, some performance-intensive path needs to test it.

3. Convert a few more direct tests of 'panicstr' to using

KERNEL_PANICKED().

Reviewed by: kib, markj, emaste
Approved by: markj (mentor)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43569