Help the stack walker to find the location of a throw statement
fix deadlock when creating a thread while executing DllMain in another thread
fix indentation
Revert "Merge pull request #92 from shoo/fix7020"

This reverts commit 29f33bfdc0d36484e77ae8f369656720319f22e3, reversing
changes made to f11dd3e56476f75804809ecc14da2e65de3f335e.

fixes Issue 7375
Bug 5547: assertPred (the druntime part)
Ensure the assert code work with pure nothrow @safe.

Also, show more digits in floating point numbers if possible.
Made capacity and reserve pure nothrow.

I don't see any reason for these not to be pure and/or nothrow, and
their lack is problematic for pure functions (and to some extent,
nothrow functions, though try-catch can fix that as tedious as it may
be).
fix Issue 8274

- drop rt_stackTop/rt_stackBottom
- add thread aware replacements in core.thread
create coverage and profile output lazily

- in shared libraries all module ctors/dtors are always executed so we
  must only create output files if these modules have actually been used
rename test to benchmark

- make room for a test suite
ModuleGroup

- bundle rt.minfo functionality in a new struct ModuleGroup so it can
  be accessed/reused for shared library handling
m_state can be HOLD

- reset is also called from the ctor so the state is HOLD
- because tstack == bstack we know it's not a paused fiber
Add atomicFence() function to core.atomic.
Remove body of atomicFence() in Ddoc mode.
SSE2 is always present on x86-64; turn atomicFence() into a naked function.
core.thread: Implement critical regions.

(Not to be confused with critical sections.)

Critical regions are areas of code where a thread absolutely must
not be suspended. Entering and exiting a critical region is very
similar to acquiring and releasing a mutex, but critical regions
do not block. They simply ensure that when the world is stopped,
a thread will not be suspended inside critical code; i.e. it will
be continually suspended and resumed until it is no longer in a
critical region.

This feature is useful to maintain invariants in garbage collectors
where you would normally use a lock. Empirically, it only happens
very rarely that a thread is suspended inside a critical region, so
the suspend/resume loop is a cheaper approach than always locking,
since locking results in high contention.

The way this commit implements critical regions, they are useful
beyond garbage collection, however; they are not specifically
coupled to any GC code.

Using critical regions is extremely error-prone. For instance,
using a lock inside a critical region will most likely result in
an application deadlocking because the stop-the-world routine will
attempt to suspend and resume the thread forever, to no avail. This
means that you really shouldn't be messing with this feature unless
you *really* do know what you're doing.
Document that critical regions are error-prone.
Merge pull request #41 from kennytm/bug5547_assertPred

Bug 5547: assertPred (the druntime part)
Merge pull request #80 from rainers/issue4809

Issue 4809: Help the stack walker to find the location of a throw statement
Merge pull request #142 from dawgfoto/fix7375

Revert "Merge pull request #92 from shoo/fix7020"