Pad m_hdr on 32bit architectures to to prevent alignment and padding
problems with the way MLEN, MHLEN, and struct mbuf are set up.

CTASSERT's are provided to detect such issues at compile time in the
future.

The #define MLEN and MHLEN calculation do not take actual compiler-
induced alignment and padding inside the complete struct mbuf into
account.  Accordingly appropriate attention is required when changing
members of struct mbuf.

Ideally one would calculate MLEN as (MSIZE - sizeof(((struct mbuf *)0)->m_hdr)
but that doesn't work as the compiler refuses to operate on an as of
yet incomplete structure.

In particular ARM 32bit has more strict alignment requirements which
caused 4 bytes of padding between m_hdr and pkthdr in struct mbuf
because of the 64bit members in pkthdr.  This wasn't picked up by MLEN
and MHLEN causing an overflow of the mbuf provided data storage by
overestimating its size.

I386 didn't show this problem because it handles unaligned access just
fine, albeit at a small performance penalty.

On 64bit architectures the struct mbuf layout is 64bit aligned in all
places.

Reported by:	Thomas Skibo <ThomasSkibo-at-sbcglobal-dot-net>
Tested by:	tuexen, ian, Thomas Skibo (extended patch)
Sponsored by:	The FreeBSD Foundation
Make the period of each periodic security script configurable.

There are now six additional variables
  weekly_status_security_enable
  weekly_status_security_inline
  weekly_status_security_output
  monthly_status_security_enable
  monthly_status_security_inline
  monthly_status_security_output
alongside their existing daily counterparts.  They all have the same
default values.

All other "daily_status_security_${scriptname}_${whatever}"
variables have been renamed to "security_status_${name}_${whatever}".
A compatibility shim has been introduced for the old variable names,
which we will be able to remove in 11.0-RELEASE.

"security_status_${name}_enable" is still a boolean but a new
"security_status_${name}_period" allows to define the period of
each script.  The value is one of "daily" (the default for backward
compatibility), "weekly", "monthly" and "NO".

Note that when the security periodic scripts are run directly from
crontab(5) (as opposed to being called by daily or weekly periodic
scripts), they will run unless the test is explicitely disabled with a
"NO", either for in the "_enable" or the "_period" variable.

When the security output is not inlined, the mail subject has been
changed from "$host $arg run output" to "$host $arg $period run output".
For instance:
  myfbsd security run output ->  myfbsd security daily run output
I don't think this is considered as a stable API, but feel free to
correct me if I'm wrong.

Finally, I will rearrange periodic.conf(5) and default/periodic.conf
to put the security options in their own section.  I left them in
place for this commit to make reviewing easier.

Reviewed by:	hackers@