Core change: XCode only install, with CLT or both

Allow XCode without the Command Line Tools to
work with homebrew, so it's not necessary
to register an Apple Dev ID and go to the
XCode prefs and download the CLT. Yay!

Further, this commit allows to use the CLT
solely (without the need for XCode).
Saves quite some megs.
(Some exceptions that require xcodebuild)

Of course XCode together with the CLT is still
fine.

New in utils:
  xcrun function to call a tool indirectly
  and smart enough to look in /usr/bin or
  query xcodes "xcrun" tool. As a final resort
  find the needed tool within Xcode Toolchains
  or in the MacOS.dev_tools_path.
  Note, xcrun has moved from ENV.rb to utils.rb
  in order to be available at all needed places.

New command_line_tools_installed? telling us
whether the CLT are installed or not.

xctoolchain_path gives the path of the
Xcode toolchain.

macosx_sdk_path(version) returning the path
of the MacOSX SDK.

ENV.macosxsdk function sets all needed lib and include
dirs to CFLAGS, CPPFLAGS, LDFLAGS.

In build.rb it is checked if Xcode >= 4.3 and
xctoolchain path exists. If yes, the new
ENV.macosxsdk(MacOSX.version) is called
to set up the environment and PATH.

--config.rb shows dev tools path and clang path

Only on Lion or above, tell the user about the options,
which are
- Xcode without CLT
- CLT without Xcode
- both (ok, it's not directly stated, but implicit)
So if no Xcode is found and we are on Lion or above,
we don't fail but check for the CLTs.
For older Macs, the old message that Xcode is needed
and the installer should be run is displayed.
If the CLT are not found but Xcode is, then we
print out about the experimental status of this setup.

A new function which uses MacOS.dev_tools_path
to find out whether cc and make are installed in /usr/bin.
This way, we avoid duplicate code.

Xcode w/o CLT now in ENV.setup_build_environment

ENV.x11 respectis macosx_sdk_path

Core-change: keg_fix_install_names now uses xcrun

lua: needs LDFLAGS, too.

cmake: Tell ./bootstrap to find the MacOSX<version>.sdk
(No more grep, thanks to ttilley!)
Corrections from code-review

- removed unnecessary "then"
- removed unnecessary "begin" block
- whitespace fixes
- use self instead of ENV
Removed line "" if clang_version.nil?

Oops. Don't know how it got there.
xcode_version's old behavior restored and new xcode_installed?

- Old behavior of MacOS.xcode_version restored
  incl. guessing of Xcode version even if no Xcode is found
 (for backwards compatibility reasons)
- New MacOS.xcode_installed?
- command_line_tools_installed? → clt_installed?
- cmake: Make the CMAKE_FIND_ROOT_PATH.txt thingy more beautiful
- --config.rb now has describe_xcode that tells us even if the version number has been guessed.
- moved the position of the function macosx_sdk_path. Now it makes more sense.
Core change: clt_installed? and clt_version

clt_installed? returns true if the default unix tools are located
at /usr or if the "Command Line Tools for Xcode" package has
been installed.

clt_version is the version string returned by pkgutil
(via pkgutil query. Thanks to camillol) for the CLT
package installed stand-alone or via Xcode's prefs.

xcode_installed? now first checks /Applications/Xcode.app,
then /Developer/Xcode.app and finally resorts to
spotlight. (thanks amillol and mikemcquaid)

added -system to the CPPFLAGS as suggested by mxcl.

--config tells about the Command Line Tools version.
wxmac: fixing compiler clang/llvm issues.

- wx 2.9 needs a patch to compile with clang when using enable-webkit
- wx 2.8 fails with clang → use llvm if MacOS.lion?
- Use new ENV.macosxsdk(version) to set 10.6 target
wxmac: need to pass --with-macosx-version-min to configure

It is not enough to set the env flags, we need to give
configure the MacOS.version, otherwise it may default to 10.5
on a 10.7 system. (This happens on Xcode 4.3 w/o CLT)
temporary adding the fails_with clang thing as a comment
vtk 5.10

- hdf5 is an optional dependency now.
- x11 reworking. cmake 2.8.8 can find the paths itself now.
- PYTHON_INCLUDE_DIR and PYTHON_EXECUTABLE have to be set,
  otherwise you get an error on "import vtk" in python since vtk 5.10.
- Cocoa is default now. So we can be less verbose.
python: move dynamic sqlite extensions to options

To avoid build problems (which lead to skipping the sqlite module),
the dynamic loadable sqlite extensions are an option now.
python: caveats print the real site-packages in effect

- Ask python where the site-packages are located. This helps us in supporting certain problems.
python: check (and warn) about ~/.pydistutils.cfg

That file may silently cause some trouble.
We had this already.
python3: Fix suggested location of symlink for framework

The old suggestion "~/Frameworks" was absolutely non-standard.
Further we do not want to overwrite the framework links from python 2.x.
python3: Add "python3" executable for --framework builds.

The "python3" is somehow forgotten for framework builds and typing python3.2 is two more chars.
Add a symlink if "python3" does not already exist.
python3: warn if ~/.pydistutils.cfg is found.

This has already proven to lead to great trouble, failed python builds and it's very hard to debug.
Users tend to forget about this hidden file or it was written by some other software.
python3: Tk warnings not necessary for Lion.
python3: added test
python3: Caveats now suggest ~/Library/Frameworks

… for an optional symlink. This is one standard location for OS X that does not require sudo.
python3: Caveats: Fix naming of easy_install

…in order to be compatible with a python 2.x install.
Usually "easy_install" refers to the python 2.x version
and "easy_install3" is the executable script for python 3.x.

foo