fork of boost-on-ios build script

the original script is located in this repository:
git@gitorious.org:boostoniphone/galbraithjosephs-boostoniphone.git

the script is forked from commit:
3c4f918cec83b2390a5e6062e32fbd7b4c275c57

the raw blob URL is this:
https://gitorious.org/boostoniphone/galbraithjosephs-boostoniphone/raw/3c4f918cec83b2390a5e6062e32fbd7b4c275c57:boost.sh
fix path in boost.sh to point to boost-trunk submodule
boost.sh: replace all things related to Subversion with similar Git commands

we don't obtain the Boost source code from the upstream Subversion repo,
instead we obtain it from a GitHub repo that is kept in sync with upstream by
its maintainer
boost.sh: use xcrun to locate the compiler, and the lipo and ar command line tools

the original script uses hardcoded paths that make assumptions about the inner
structure of an Xcode.app bundle. this is sure to fail as soon as Apple changes
something inside Xcode (there are reports that Xcode 5 already brings such a
change). a symptom of the problem is an error such as this:

sh: /Volumes/Xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++: No such file or directory
remove the Mac OS X build from boost.sh

we don't need the Mac OS X build because this repo is interested only in
providing a Boost version for Fuego on iOS
boost.sh: fix "toolset" parameter on bjam command line

Boost 1.54.0 has some internal changes that cause the simulator build to fail with
the current bjam command line that only uses "toolset=darwin". the solution is to
use different values for the "toolset=" parameter for the iPhone and the simulator
build. the value that we use now selects the appropriate configuration from the
user-config.jam file ("toolset=darwin-$IPHONEOS_BJAM_TOOLSET" and
"toolset=darwin-$IPHONE_SIMULATOR_BJAM_TOOLSET")

a symptom of the problem is when the compiler executable is not found and
the build fails with this error:

/bin/sh: line 1: -ftemplate-depth-128: command not found

the source of the fix is this Stack Overflow post:
http://stackoverflow.com/questions/17714635/how-can-i-compile-boost-1-54-0-1-54-for-the-ios-simulator-6-1-on-os-x-10-8-4
add compiler flags to boost.sh that allow to specify the deployment target

the deployment target is the minimum required version of iOS.
boost.sh: handle object files with same name in different libraries

it is possible that object files with the same name are present in multiple
libraries. for instance, utf8_codecvt_facet.o is present both in filesystem
and in program_options. the current decomposing mechanism cannot
handle this and clobbers the first object file with the second file. as a result,
the build of an iOS app that ends up consuming the boost framework
may fail with a weird linker error that complains about missing symbols. the
reason is that the object files - despite having the same name - contain
different symbols (because each Boost library has its own namespace that
is then encoded into the symbol names). when one of the object files is
overwritten, its symbols are lost and will not be present in the final
libboost.a uberlib.

the fix for this is simply to use library-specific obj folders when libraries
are decomposed.

an example linker error:

Undefined symbols for architecture i386:
  "vtable for boost::filesystem::detail::utf8_codecvt_facet", referenced from:
      boost::filesystem::detail::utf8_codecvt_facet::utf8_codecvt_facet(unsigned long) in AppDelegate.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
add .gitignore
boost.sh: build libraries required by fuego
boost.sh: update SDK version to 6.1
add Xcode project that builds Fuego as a static library

the only files that are not part of the build are
- FuegoMain.cpp: Contains the main() function which is
  not needed in a library
- SgProcess.cpp: Fixes a compiler error in SgProcess.h
where a GCC specific header is included
- SgProcess.h: Since SgProcess.cpp is not included in
the build, there is no point in making this file a
public header

the files are added to the project, but they are disabled
for the build target
add simple shell script to build Fuego

the purpose of the script is to run the build twice with xcodebuild:
one time for the device and one time for the simulator. when the
build finishes, the script "handcrafts" a framework bundle folder
and copies everything from the build folder into the bundle folder
build both Boost and Fuego with -std=gnu++98 and -stdlib=libstdc++

building with -stdlib=libc++ causes Fuego to deadlock on startup (at least
when tested in Little Go); the issue goes away when the libstdc++
implementation of the C++ standard library is used.

since libc++ is no longer used, it also does not make sense to keep
-std=c++11; to remain consistent this is therefore changed to
-std=gnu++98
use compiler "clang" instead of "clang++" to build Boost

Xcode projects by default use "clang" and not "clang++"; the mismatch in
compiler names between Boost and any Xcode builds causes large
amounts of linker warnings when the final iOS application that consumes
Fuego/Boost is built. the reason why these warnings occur is not known,
but changing the compiler name for the Boost build to "clang" fixes the
issue.

example linker warnings:

ld: warning: direct access in ___cxx_global_var_init to global weak symbol
std::__1::basic_ofstream<char, std::__1::char_traits<char> >::~basic_ofstream()
means the weak symbol cannot be overridden at runtime.
This was likely caused by different translation units being compiled with different visibility settings.

ld: warning: direct access in __GLOBAL__I_a to global weak symbol
boost::exception_ptr::~exception_ptr()
means the weak symbol cannot be overridden at runtime.
This was likely caused by different translation units being compiled with different visibility settings.
fuego-on-ios.xcodeproj now defines the NDEBUG macro

if NDEBUG is not defined and Fuego is run with --quiet, an assertion in SgDebug()
will fail, causing the program to abort. In SgDebug.cpp:

    if (! g_debugStrPtr->good())
    {
        // does not just use a direct SG_ASSERT(g_debugStrPtr->good())
        // in order to allow a breakpoint to be set on the line below.
        SG_ASSERT(false);
    }

The check whether the debug stream is good fails when --quiet is specified.
NDEBUG must be defined so that the SG_ASSERT macro will expand to
nothing.
build script no longer writes a build.log file
add README.md