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
wxmac: fails_with :clang unless --devel
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!)
fix xcode_installed? on older systems

- The right path to Xcode was /Developer/Applications/Xcode
- Look for bundle identifier com.apple.Xcode AND com.apple.dt.Xcode
- style and whitespace fixes
unless is not if not. It's less.

undoing too many `unless`s.
MacOS.xcode_prefix uses same mdfind command as xcode_installed?

- The old "kMDItemDisplayName==Xcode&&kMDItemKind==Application" could hang if spotlight has not indexed.
- Now using the two different possible bundle identifiers for the search (thanks to @camillol)
Xcode is no more an installer. Other minor misc things.

- Make describe_xcode more beautiful and tell us about non standard path to Xcode.app.
- We had one case where Xcode.app was found in Downloads.
- Minor: unrar needs to be installed (it is not there on a fresh Lion)
syntax error
global: Add MacOS.dev_tools_path to PATH
global.rb: avoid leading ':' in ENV['PATH']
Revert "global.rb: avoid leading ':' in ENV['PATH']"

This reverts commit 70bcf34f720df2046e9f2c958e8e08e6af5affc9.
--config less verbose. Code cleanup.