add the 'download_file' command when setting up linux schroot environment
install the "fpm" and "ronn" ruby gems into the schroot environments

These will be useful for generating distribution-specific binaries
(using fpm) and generating HTML/man pages (using ronn) from Markdown
files created by migrating the existing documentation embedded in
the source code.
fix compilation error for linux builds due to missing iconv support

This is required since 3ac41fae4b962ae0bbeacad74a4ccb9a6012d0b2 as the text
codecs are built on Unix-like environments only if iconv support is enabled.
do not share a common build directory during the compilation process

This can be harmful because the shared library and the applications may
be built with different compilation/linkage options and may give an error.
generate native packages for the target linux distribution using "fpm"

For the Debian-based distributions, we use XZ compression which results
in packages which have the same size as the tarballs which were generated
earlier. Unfortunately, there is no support for using XZ compression in
CentOS 5/6 and hence we have to use bzip2 which increases the file sizes
quite a bit (tarballs were around 16MiB while the package is around 42MiB).

All the native packages should have correct dependency information, but it
would unadvisable to install a package on a different distribution as only
the package names are specifed without specifying any version numbers.
refactor the OS X build system to use latest libjpeg/libpng libraries

Earlier, the bundled versions of the above libraries were used, which is
not safe as there might be security vulnerabilities in those versions.
The framework introduced in 9db4dce10d8ba81cb854d6994a842b6c9d149726 to
support building dependent libraries for Windows was reused to download
and compile the latest versions of the above libraries.

In addition, the build system was refactored to use "make install" support
which was introduced in bd16273f806759d82c9f64abaa2c093a76442dad for Linux.
generate native PKG for OS X using "fpm"

On OS X, packages are very limited and do not have the functionality that is
provided by package managers on Linux/BSD systems -- installation is supported,
but no uninstallation. Also, the compression support for packages is very poor
-- a 92MiB package is generated instead of a 14MiB tarball compressed using xz.

Thus, we use a very ugly hack to get the package down to a reasonable size. We
actually create a compressed tarball using xz (as before) and include a after-
install script which decompresses this tarball into /usr/local. To support the
scenario where the end-user might not have xz installed on the machine, a copy
of unxz is also bundled in the package.
include updated VERSION when generating the source tarball

This ensures that the commit hash is included in the compiled version
when a source tarball is generated for a development snapshot.
add script for building of releases for the current platform

Note that this always assumes that you are running on 64-bit OS.
build the source tarball and MinGW-w64 targets when releasing on Linux
skip logging repeated lines due to progress bars in the release script
fix the Windows installer to install to correct directory on 64-bit OSes
update README and CHANGELOG
improve error reporting for failed commands in build script
fixes in the OS X package installation and add script for uninstallation
download/compile xz for building/decompressing tarball in OS X installer

On OS X, we previously packed a locally installed xz into the installation
package and unpacked it during installation, if xz is not available on the
target machine. This can lead to problems if xz was installed by a package
manager like Homebrew, as symlinks would get packed instead of the real
binary.

We now download and compile xz statically on the fly, which removes the
need for xz on both the developer and the deployment machine.
document that encrypted home directories are not supported

According to the Debian/Ubuntu bug, there is a workaround but
it is not always safe to use, hence document that it is not supported.
Closes #1793
fix error for the "posix-local" target in build script

This fixes #1800 in a slightly different manner.
document that the home directory should be in /home for linux builds

Otherwise, it does not get automatically mounted in the schroot.
Recommend using a VM in case of such a scenario. Closes #1804.
perform release builds in the specified order