Add initial support for Mac OS X 10.7 (Lion). Tracked by bug #275168.

Add initial support for Mac OS X 10.7 (Lion).  Tracked by bug #275168.

* configure.in support

* new supp file darwin11.supp

* comment out many intercepts in mc_replace_strmem.c and
  vg_replace_malloc.c that are apparently unnecessary for Darwin

* add minimal handling for the following new syscalls and mach traps:
    mach_port_set_context
    task_get_exception_ports
    getaudit_addr
    psynch_mutexwait
    psynch_mutexdrop
    psynch_cvbroad
    psynch_cvsignal
    psynch_cvwait
    psynch_rw_rdlock
    psynch_rw_wrlock
    psynch_rw_unlock
    psynch_cvclrprepost

* wqthread_hijack on amd64-darwin: deal with
  tst->os_state.pthread having an apparently different offset,
  which caused an assertion failure

* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
  cleanup added in r12041/12042 to handle apparently new dyld
  behaviour, which is to map text areas r-- first and only
  vm_protect them later to r-x.

The following cleanups remain to be done

* remove apparently pointless, commented out wrapper macro
  invokations in mc_replace_strmem.c, eg

  //MEMMOVE(VG_Z_DYLD,        memmove)

  (or determine that they are still necessary, and uncomment)

* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
  there

* write proper syscall wrappers for
    mach_port_set_context
    task_get_exception_ports
    getaudit_addr
    psynch_mutexwait
    psynch_mutexdrop
    psynch_cvbroad
    psynch_cvsignal
    psynch_cvwait
    psynch_rw_rdlock
    psynch_rw_wrlock
    psynch_rw_unlock
    psynch_cvclrprepost
  These are currently just no-ops and may be causing Memcheck to
  report false undef-value errors

* figure out why it doesn't work properly unless built with gcc-4.2 on
  Lion.

  gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1).  Plain
  gcc is the hybrid gcc-front-end clang-back-end thing
  (i686-apple-darwin11-llvm-gcc-4.2).  Whereas on Snow Leopard, plain
  gcc is the normal gcc.

  The symptoms of the failure are that wqthread_hijack in
  syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
  at the end (you need a pretty complex threaded app to trigger this),
  which makes me think that either ML_(wqthread_continue_NORETURN) or
  call_on_new_stack_0_1 do return, which they are not expected to.

* figure out if some of the uninitialised value errors reported in
  system libraries on are caused by Memcheck being confused by LLVM
  generated code, as per bug #242137

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043 a5019735-40e9-0310-863c-91ae7b9d1cf9