Recognize -arch amd64|x86_64 for consistency
Allow -arch to switch between 32bit/64bit targets

So, on a 32bit host system there can be two ways to cross-compile to
64bit:

a) fbc -target x86_64-pc-linux-gnu
   - which will use x86_64-pc-linux-gnu-{gcc,as,ld}, i.e. a full-blown
     x86_64-pc-linux-gnu cross toolchain)

b) fbc -arch x86_64
    - which will use "gcc -m64", "as --64" and "ld -m elf_x86_64" (Linux)
      or "ld -m i386pep" (Windows)

On common Linux distros, there usually is a gcc multilib (gcc -m32/-m64)
toolchain available, but not a full cross-compiler to 32/64bit. So it's
probably best for fbc to make use of gcc -m32/-m64 too, if no explicit
target such as x86_64-pc-linux-gnu was given.

It's the same with 64bit host systems and cross-compiling to 32bit.

This pretty much affects the normal build only, because the standalone
build will only use the tools from its bin/win64/ or bin/linux64/
directories.

This patch changes the fbc frontend to always pass -m32/-m64 to gcc (for
both the C backend and the gcc -print-file-name queries used by the normal
build to find library files on the system), --32 or --64 to GNU as, and
also -march correspondingly for llc (for the LLVM backend).

In theory passing these options would only be needed when compiling for
another arch than which the tool produces by default, but we might not
always know. For example, with the normal 32bit fbc on a 64bit system,
we will still use the system GNU as, and then we need --32 because
otherwise it would probably default to --64.

In theory we wouldn't need to pass the explicit 32/64bit options to the
tools included in the standalone build, because we have control over them
and can ensure they produce the expected arch by default. But as long as
there are no issues, it's not worth it to add more #ifdefs.
Also recognize -arch 32/64 shortcuts, like gcc -m32/-m64