todo: Remove entries for issues related to -print/64bit

Since f3e5b160 this problem is solved. -print host/target will print
"win32" or "win64" or "linux-x86", etc., so not just the operating system.
Don't escape backslashes when invoking ld on DOS (2783274f regression)

Commit 2783274f changed fbc to escape \ as \\ in @files when invoking ld.
We use "ld @ldopt.tmp" with the file "ldopt.tmp" containing the ld command
line options on DOS and Win32 to work-around the command line length
limits. (on DOS we always use it because our ld command line is always
longer than the 127 char limit; on Win32 we only use it if the command line
is longer than the 8k limit)

This works on Win32 because the MinGW ld accepts \\ as \ in @files. This
has fixed bug #701. -Wl --verbose output confirms that ld turns \\ back
into \ as documented for its @file command line option.

Note however that DJGPP ld does not seem to accept \\ as \ in @files.
It silently works with the DJGPP ld on Win32 because the OS accepts \\ as
path separator, but -Wl --verbose output shows that ld itself does not
turn \\ into \, despite what the binutils ld @file documentation or DJGPP
FAQ says. It's not quite clear whether the @file will be evaluated by the
DJGPP runtime or by ld itself (maybe it also depends on how the DJGPP ld
is invoked).

Thus, the change to use \\ instead of \ has broken fbc on DOS on systems
which don't accept \\ as path separator:
http://www.freebasic.net/forum/viewtopic.php?f=4&t=22867

This commit should fix that issue.
makefile: Add note about MAKEFILE_LIST not being available in DJGPP's make
makefile: Fix contrib/djgpp/libc/crt0/_main.o build for separate build dir

It wasn't possible to build the DOS version in a separate build directory,
because the part which builds contrib/djgpp/libc/crt0/_main.o assumed that
build dir = source dir.