If it isn't possible to determine the realpath() of ".", then simply
give up on attempting to resolve any relative path - there's no hope.

Make realpath(1) compat with the planned (not yet approved) specification
for POSIX.8 (its next version). (Should the requirements change, the code
here can be updated).

This adds two new options. -e and -E
-e just tells realpath to do what it has done since it was imported here.
-E makes realpath more compatible with the coreutils version, and allows
the final component of the path to not exist (the final component after
all symlinks have been expanded, not of the arg on the command line - though
that one not existing is one case of the more general spec.).

POSIX is not going to specify which of those is the default - instead is
planning to require users to always explicitly specify one.

The default (now) here is -E. This makes us more compat with coreutils.
realpath was added in the first place because it is (apparently) used in
real world scripts - the more we can support, the better.

Note that in all cases where realpath -e succeeds, realpath -E will succeed
as well. This means that any uses of "realpath file" that have been
working in HEAD will still work. Some cases that would have failed
will work (by default) now.

branches: 1.1.4;
Port realpath(1) from FreeBSD

realpath(1) wraps realpath(3) and returns resolved physical path.

This utility shipped with GNU and FreeBSD is sometimes
used in scripts in the wild.