error.jl: add application-oriented assertion facility

This modification to error.jl adds a module named Assertions and a top-level macro which can be called in essentially one of two ways:
<pre><code>
 @ASSERT &lt;condition&gt;
 @ASSERT (&lt;condition&gt;, &lt;expr&gt; ....)
</code></pre>

Please see the "Design FAQ" at http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html 
for the general rationale for having this kind of application-oriented assertion facility as part of the core language. (Two relevant paragraphs are appended below at (*).)  

There are as best I can tell two other reasons:

1. the facility should print the file and line number of an assertion violation;
2. the ability to turn assertion checking off when invoking julia. 

The key features of this application-oriented assertion facility are:
1. it is very simple to use;
2. there is virtually no overhead if assertion-checking is turned off;
3. assertion violations do not raise a run-tim error condition unless a flag specifies otherwise;
4. errors in assertion specifications should not raise run-time errors;
5. if @ASSERT returns a value, it is nothing.

Further details are in error.jl; these should ultimately be migrated to Julia documentation.

PLEASE NOTE THAT THERE ARE STILL SOME BOOTSTRAPPING ISSUES TO BE RESOLVED.

The additional code can be exercised by moving it to a separate file.

(*)
Excerpts from http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html 

> Why provide an assertion facility, given that one can program assertions atop the Java programming language with no special support?
Although ad hoc implementations are possible, they are of necessity either ugly (requiring an if statement for each assertion) or inefficient (evaluating the condition even if assertions are disabled). Further, each ad hoc implementation has its own means of enabling and disabling assertions, which lessens the utility of these implementations, especially for debugging in the field. As a result of these shortcomings, assertions have never become a part of the culture among engineers using the Java programming language. Adding assertion support to the platform stands a good chance of rectifying this situation.

> Why does this facility justify a language change, as opposed to a library solution?
We recognize that a language change is a serious effort, not to be undertaken lightly. The library approach was considered. It was, however, deemed essential that the runtime cost of assertions be negligible if they are disabled. In order to achieve this with a library, the programmer is forced to hard-code each assertion as an if statement. Many programmers would not do this. Either they would omit the if statement and performance would suffer, or they would ignore the facility entirely. Note also that assertions were contained in James Gosling's original specification for the Java programming language. Assertions were removed from the Oak specification because time constraints prevented a satisfactory design and implementation.