Change target platform naming conventions

This affects the -target option, the compiler directory layout, -v output,
etc.

FB's old format (32bit x86 only):
	dos
	win32
	linux
	freebsd
	...

Initial new format when 64bit/ARM support was added:
	dos
	win32
	x86_64-win32
	linux
	x86_64-linux
	armv6-linux
	aarch64-linux
	freebsd
	x86_64-freebsd
	...

Format introduced by this commit:
	dos
	win32
	win64
	linux-x86
	linux-x86_64
	linux-arm
	linux-aarch64
	freebsd-x86
	freebsd-x86_64
	...

I believe this new format is better for the following reasons:

* Obviously the 64bit/ARM support requires some sort of change to allow
  lib/ directories for multiple targets to co-exist.
* The format introduced in b0847a09 (linux/win32 = x86,
  x86_64-linux/x86_64-win32 = x86_64) is confusing. It's not clear that
  "linux" refers to x86 Linux, and "x86_64-win32" contains "32" even though
  it's 64bit. The new format avoids this confusion by using "linux-x86"
  and "win64" for these two cases.
* dos/win32 (and xbox) don't change. This is what most users know since
  FB was first released - it's good to avoid changing this unless really
  necessary. For now it's not necessary though: dos is always x86, so we
  don't need to bother calling it dos-x86. win32 also is clear in that it's
  32bit, and traditionally refers to x86 PCs.
* win64 follows the same idea as win32 except it's 64bit.
* The names for linux/freebsd/etc. targets change, but that's a necessary
  evil. There is much more variety in the Linux/BSD world than on Windows.
  Linux/BSD users should also be able to cope with the change... and of
  course people will probably not touch the lib/freebasic/ directory of
  FB installations on Linux as much as the lib/ directory of an FB setup
  on Win32, because they can install libraries elsewhere in the system,
  and don't have to copy them into the lib/win32/ directory. Thus they may
  not even notice the change (and that's ok too).
* The <os>-<cpufamily> format sorts nicely.
* The new naming convention can be used as-is for FB release packages,
  resulting in nice consistency.

It's likely that further adjustment will be needed in the future, for
example I'm not sure whether linux-arm will be enough for ARM support.
Perhaps we'll need linux-armv6, linux-armv7, etc. On the other hand, we do
not have (and never had) specific lib/ directories for each x86
architecture either (e.g. win32-i386, win32-i486, win32-i586, win32-i686).

Even though the -arch option allows selecting specific CPUs of the x86 or
ARM family, it does currently not affect the choice of lib/ directory,
making it useless for the purposes of enforcing the use of a certain
instruction set only.

Whether we want to change that in the future (and encode the exact CPU name
and perhaps even more information such as hard-float/soft-float into the
FB target names) is outside the scope of this commit though.