MAP_{NORESERVE,LOCKED} have different values on powerpc than in generic.

currently five targets use the same mman.h constants and the rest
share most constants too, so move them to sys/mman.h before the
bits/mman.h include where the differences can be corrected by
redefinition of the macros.

this fixes two minor bugs: POSIX_MADV_DONTNEED was wrong on most
targets (it should be the same as MADV_DONTNEED), and sh defined
the x86-only MAP_32BIT mmap flag.

they lock faulted pages into memory (useful when a small part of a
large mapped file needs efficient access), new in linux v4.4, commit
b0f205c2a3082dd9081f9a94e50658c5fa906ff1

MLOCK_* is not in the POSIX reserved namespace for sys/mman.h

this flag for strong access ordering was added in linux v2.6.27
commit aba46c5027cb59d98052231b36efcbbde9c77a1d

the definitions didn't match the linux uapi headers.

the definitions are generic for all kernel archs. exposure of these
macros now only occurs on the same feature test as for the function
accepting them, which is believed to be more correct.

these are also needed by qemu.

both kernel and glibc define it only on x86(_64).

this is needed for qemu, and since it differs for each arch
it can't be circumvented easily by using a macro in CFLAGS.

this is actually rather ugly, and would get even uglier if we ever
want to support further feature test macros. at some point i may
factor the bits headers into separate files for C base, POSIX base,
and nonstandard extensions (the only distinctions that seem to matter
now) and then the logic for which to include can go in the main header
rather than being duplicated for each arch. the downside of this is
that it would result in more files having to be opened during
compilation, so as long as the ugliness does not grow, i'm inclined to
leave it alone for now.

based on patch by nik