Add /private/var/mail to darwin_native sandbox

[jlmuir]

This makes the configure phase of pkgsrc's mail/neomutt work because it has an Autotools configure check for "where new mail is stored" which roughly does the following:

mutt_cv_mailpath=no
if test -d /var/mail; then
  mutt_cv_mailpath=/var/mail
elif test -d /var/spool/mail; then
  mutt_cv_mailpath=/var/spool/mail
elif test -d /usr/spool/mail; then
  mutt_cv_mailpath=/usr/spool/mail
elif test -d /usr/mail; then
  mutt_cv_mailpath=/usr/mail
fi

Since /var/mail nor any of the other paths exist in the sandbox, the configure script fails like this:

checking where new mail is stored... no
configure: error: "Could not determine where new mail is stored."
*** Error code 1

This change is really just a change to make the sandbox more like outside the sandbox so that a particular pkgsrc package will build. In this case, the package is mail/neomutt. I don't know if any other pkgsrc package would benefit.

Another approach would be to change pkgsrc's mail/neomutt/Makefile to invoke the configure script with --with-mailpath=/var/mail for Darwin. But it seems like a tough sell to get that committed because it seems like a bad idea to be making changes to pkgsrc packages to make them build successfully in a particular sandbox. Ideally the sandbox should enable packages to build just like outside the sandbox.

Depending on how realistic /var/mail should be in the sandbox, it could instead be returned by the _darwin_native_bindfs_mounts function, but since other things in /var were being faked (i.e., just being created in the sandbox and not using a null-mount), the change just adds it in the darwin_native_create function with the other faked things.

[jmmv]

Merged as 7c9de79. Same as with the other PR: modified your change to rebase it with HEAD and to add a NEWS entry.