Fix dbgshim race conditions

Fix dbgshim race conditions

There are two race conditions in the register runtime startup logic: 1) in
CreateProcess (or CreateProcessForLaunch) between the fork() and the execv()
where for VS and mdbg we "see" the coreclr module loaded because the debugger
process and newly created child have the same modules loaded. 2) in attach
between when the child/debuggee loads the coreclr module and when coreclr
finishes initializes the global dac table. In both causes DebugActiveProcess
returns an error when one of the race conditions is hit.

The fix is to create the "continue" named semaphore on the coreclr/debuggee
process side and dbgshim uses that to determine if the coreclr process is
ready and initialized. Fixes issue #4244.

Open the old continue semaphore name and if it doesn't exists create a the new
continue semaphore name for backwards compatibility (see issue 4410).

Do PAL initalization on entry to the public functions instead of the DLLMain handler
which will only be called if the PAL's LoadLibrary is used to load dbgshim. It will be
a lot easier on the debuggers like mdbg to just use dlopen/dlsym and not have to
also call DLLMain.