fix Makefile so "make install" works before include/bits symlink exists

previously, determination of the list of header files for installation
depended on the include/bits symlink (to the arch-specific files)
already having been created. in other words, running "make install"
immediately after configure without first running "make" caused the
bits headers not to be installed.

the solution I have applied is to pull the list of headers directly
from arch/$(ARCH)/bits rather than include/bits, and likewise to
install directly from arch/$(ARCH)/bits rather than via the symlink.

at this point, the only purpose served by keeping the symlink around
is that it enables use of the in-tree headers and libs directly via -I
and -L, which can be useful when testing against a new version of the
library before installing it. on the other hand, removing the bits
symlink would be beneficial if we ever want to support building
multiple archs in the same source tree.
add stubs for additional legacy ether.h functions

these would not be expensive to actually implement, but reading
/etc/ethers does not sound like a particularly useful feature, so for
now I'm leaving them as stubs.
paths.h: remove cruft

a research in debian codesearch and grepping over the pkgsrc
directory tree have shown that these macros are all either unused,
or defined by programs in case they need them.
add legacy scsi/scsi_ioctl.h header
add legacy sys/ttydefaults.h header
move alignment check from aligned_alloc to posix_memalign

C11 has no requirement that the alignment be a multiple of
sizeof(void*), and in fact seems to require any "valid alignment
supported by the implementation" to work. since the alignment of char
is 1 and thus a valid alignment, an alignment argument of 1 should be
accepted.
move core memalign code from aligned_alloc to __memalign

there are two motivations for this change. one is to avoid
gratuitously depending on a C11 symbol for implementing a POSIX
function. the other pertains to the documented semantics. C11 does not
define any behavior for aligned_alloc when the length argument is not
a multiple of the alignment argument. posix_memalign on the other hand
places no requirements on the length argument. using __memalign as the
implementation of both, rather than trying to implement one in terms
of the other when their documented contracts differ, eliminates this
confusion.
add NFDBITS in sys/select.h with appropriate feature tests

the main use for this macro seems to be knowing the correct allocation
granularity for dynamic-sized fd_set objects. such usage is
non-conforming and results in undefined behavior, but it is widespread
in applications.