GetProgPath() now resolves the path derived from argv[0] always
via realpath(3p) to its real location in the filesystem, and returns
the path including binary name, effectively making it work like
windows' GetModuleFileName(), so we can re-use the existing code
to strip the trailing binary name.
since symlinks are now always resolved, we no longer need the
special case code for linux to use /proc/self/exe for this purpose.
there was some concern that this will break windows' way of doing
file lookups relatively from the binary, rather than via hardcoded
locations, but so far each occurence adding e.g. "CA65_INC" to
the pathsearch is already shielded with an #ifndef _WIN32.
addressing #1726
until now, the strings intended to be hardcoded into the binary,
such as directory names and build id, were passed unquoted, which
means they're interpreted by the preprocessor as C tokens, rather
than strings, which can result in all sorts of "interesting"
behaviour such as interpreting paths starting with // as C++-style
comment.
this was then worked around using a stringize macro which turned
the tokens into a string (if they happened to be in a compatible
format).
adresses #1726
it's often required to see the full commandline when things go wrong.
the standard way for Makefile-only based buildsystems and autoconf
is to pass V=1 to make.