swift234

[stdlib] Implement a sane assert/fatal error check system

The facility we had before was not very usable in core elements of the
standard library because it relied too much on those elements itself.
The result could be some spectacular infinite recursions and general
erosion of certainty, and was making development of Swift's String very
difficult.

In this commit we use extremely low-level primitives to avoid the recursion
problem.  Also, because the purpose of all the older assertion functions
was unclear and there was a great deal of overlap in terms of
functionality, we clarify naming and consolidate functions.

As much as possible, the semantics of all existing tests in the face of
Asserts-enabled/-disabled build configuration changes has been
preserved, but the new naming makes it obvious in some cases that the
semantics may not have been well-chosen, which speaks well for the new
names. (**)

The two forms of "assert()" are completely enabled or
disabled--including evaluation of the condition--based on build
configuration.  This follows the usual semantics from C, with the
differences being:

  * No multiple evaluation badness from preprocessor macros, of course
  * When a condition is supplied, assert accepts an optional message
  * When no condition is supplied, fires unconditionally and requires a
    message

The other functions are always enabled and only differ between build
configurations in how much information they attempt to deliver through
non-core-dump channels.  When assertions are disabled and these
functions fire, they invoke a debugger trap, and do nothing else.

(**) It also opens some questions about policy.  For example, should we
consider overflow and underflow to be securityChecks, as we do now, even
though they do not directly cause a memory safety issue?  We could wait
for e.g. bounds checking on arrays to catch those problems before they
become memory safety issues, and gain a little speed in the regular
arithmetic path.

Swift SVN r12854