Don't include locked memory in coredumps

Linux 3.4+ supports a DONTDUMP advisory, which prevents memory
from being included in coredumps. Would this be worth doing as
part of mlock()?
Handle madvise() failure on stale kernel

MADV_DONTDUMP may be defined by the system headers, but not supported
by the running kernel. In this case madvise() returns EINVAL. We should
treat this as an expected error, rather than a fatal one.

An argument could be made for ignoring madvise()'s return value entirely,
but this change seems more in line with the existing code base.
Call madvise() on a best effort basis

This change ignores the return value of madvise(), a bad practise in general -
but on reflection, what can we (or a caller) really do about it anyway?
Remove the recommendation to use random bytes for nonces

My reading of randombytes_buf() is that it generates a byte buffer from a
source of random data that is likely to be uniformly random.

Although it's highly likely that crypto_box_NONCEBYTES of data will be unique
for most applicaiton invokations, there doesn't appear to be any kind of
gaurantee; and how should the implementor reason about re-keying? When they've
sent 2 ^ (crypto_box_NONCEBYTES * 8) bytes, or before?

Would things be simpler and more clear with partitionable sequences?
Lenghtier note on nonce practices
neglible -> negligible
(void) madvise
Don't include locked memory in coredumps

Linux 3.4+ supports a DONTDUMP advisory, which prevents memory
from being included in coredumps.
Merge branch 'master' into doc

* master:
  Don't include locked memory in coredumps
Just say "ignore" instead of "de-duplicate"
Merge remote-tracking branch 'upstream/doc' into doc

Conflicts:
	doc/public-key_cryptography/authenticated_encryption.md
	src/libsodium/sodium/utils.c