Restructuring the download archive

[Johannes Pfau via D.gnu]

I thinks it's time to push some new binary releases to 
gdcproject.org (gcc-5, intrinsics for checkedint, ...). We should 
first get some structure into our download archive though: 
ftp://ftp.gdcproject.org/binaries/

The first question is whether we can break old download links. 
I've hardcoded one or two toolchain URLs in the build scripts, 
but that could be changed easily.


Another question is how exactly the new directory layout should 
look like. I think we definitely need host folders as a top-level 
structure:

/binaries
  |- x86_64-linux-gnu
  |- x86_64-w64-mingw32
  |- arm-linux-gnueabi

Do we want to have the target as a directory? GCC version? 
Frontend version?
I think the frontend version is usually more important for users 
than gcc version. So if we don't use the GCC version we still 
have two options. dmdversion/target or target/dmdversion:

/binaries
  |- x86_64-linux-gnu
  |  |- 2.061
  |  |  |- x86_64-w64-mingw32
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
  |  |  |- arm-linux-gnueabi
  |  |- 2.062
  |- x86_64-w64-mingw32
  |- arm-linux-gnueabi

Another question: DMD frontend sub-releases in one folder? 
(2.061|2.061.1|2.061.2)

We could also use symlinks for tools to point to the latest 
releases:

/binaries
  |- x86_64-linux-gnu
  |  |- 2.061
  |  |  |- x86_64-w64-mingw32
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
  |  |  |- arm-linux-gnueabi
  |  |  |- x86_64-w64-mingw32_2.061_LATEST.tar.xz
  |  |- 2.062
  |  |- x86_64-w64-mingw32_LATEST.tar.xz
  |- x86_64-w64-mingw32
  |- arm-linux-gnueabi

And how should we present naive releases? Some folder structure 
and target as usual or we could use some other name for target 
(e.g. native). We could also skip the target directory for native 
builds:

/binaries
  |- x86_64-linux-gnu
  |  |- 2.061
  |  |  |- x86_64-w64-mingw32
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
  |  |  |- arm-linux-gnueabi
  |  |  |- x86_64-w64-mingw32_2.061_LATEST.tar.xz
  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_AAAA_20150405.tar.xz
  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_BBBB_20150405.tar.xz
  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_CCCC_20150405.tar.xz
  |  |- 2.062
  |  |- x86_64-w64-mingw32_LATEST.tar.xz
  |- x86_64-w64-mingw32
  |- arm-linux-gnueabi

However, this could get confusing as we'll have many files in the 
dmdver folders. We could also move the -LATEST links into the 
target dirs for all builds except for native ones. This way 
native builds will be more prominent:

/binaries
  |- x86_64-linux-gnu
  |  |- 2.061
  |  |  |- x86_64-w64-mingw32
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_AAAA_20140430.tar.xz
  |  |  |  |- 
x86_64-w64-mingw32_2.061.2_gcc4.8.2_BBBB_20140430.tar.xz
  |  |  |  |- x86_64-w64-mingw32_2.061_LATEST.tar.xz
  |  |  |- arm-linux-gnueabi
  |  |  |- x86_64-linux-gnu
  |  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_AAAA_20150405.tar.xz
  |  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_BBBB_20150405.tar.xz
  |  |  |  |- x86_64-linux-gnu_2.061_gcc4.9.2_CCCC_20150405.tar.xz
  |  |  |- x86_64-linux-gnu_2.061_LATEST.tar.xz
  |  |- 2.062
  |  |- x86_64-w64-mingw32_LATEST.tar.xz
  |- x86_64-w64-mingw32
  |- arm-linux-gnueabi
  |- x86_64-linux-gnu_LATEST.tar.xz