Change for freeing msg header and data storage: when not in hyper-alloc

mode, a freeing of header or data storage at the end of the file will now
result in the file (the allocation file *and* the data/hdr file) being
truncated - saving potentially many megabytes of disk space for
non-maintained msg bases (e.g. the mail base). Previously, self-packing
and fast-alloc msg-bases would never shrink without running smbutil m,
but that's now no longer true.

Something similar could be done for hyper-alloc msgbases, but I'm not sure
that's really needed since the email base can never be hyper-allocated and
this change was really for the email msgbase where allocation files are a
must due to the multiple-recipients/headers per msg data feature.