Initial pass at OS X support.
It still unwinds on linux. It doesn't succeed on OS X yet, but its not failing to compile/crashing anymore.
In the same vein as "COR" and "URT", the terms "COM+"/"COMPLUS" appear frequently throughout the codebase, most notably in config settings (e.g. "COMPLUS_DefaultVersion"). I couldn't find any other explanation for what this means, and since I remember learning about it myself by asking older members of the team, I thought it would be helpful to have this documented for newcomers to the codebase.
Any managed code that touches the ThreadPool is currently crashing when the ThreadPool tries to initialize. This is due to it creating a semaphore via CreateSemaphoreExA/W in the pal, and those functions not being implemented. This commit just implements those functions by delegating to their non-Ex counterparts. With this change, ThreadPool.QueueUserWorkItem, Task.Run, etc. are able to successfully schedule work and have it executed.
The current PAL has binary check-ins of the config.h for Linux and MAC, long term this is not sustainable. This is a first pass at cleaning this up. Please note, there are some static platform independent defines as I tried to keep consistency with the current outputs of the not-checked-in configure.in. As we clean up the PAL the CMakeLists should be revisited and redundant pieces removed.
libunwind on linux exposes the unw_context_t directly as a ucontext_t, but on OSX its an opaque data structure. Additionally UNW_REG_SP is read/write on OSX, but read-only on Linux. As such we need to diverge the libunwind code a bit depending on what flavor we are running on. There is one OSXTODO around the context pointers, since we do not have unw_get_save_loc on OSX.
@mmitche There is something strange going on with the windows build. It fails with