Bug 645416, part 3 - Symbol layout and GC support for allocating them. r=terrence.

Layout: js/src/vm/Symbol.h defines the new class JS::Symbol. JS::Symbol is the
same size as JSString on all platforms, because the allocator does not support
smaller allocations.

Allocation: Since the purpose of symbols is to serve as property keys, they are
always allocated in the atoms compartment.

We take a lock when allocating. This could probably be replaced with a
main-thread-only assertion. However, if atom allocation is not already a
bottleneck, symbol allocation probably never will be.

Symbols are given their own finalize-class in the GC. This means we allocate a
page per zone for symbols, even though they are only ever allocated in the
atoms zone. Terrence thought this could be easily fixed later. It should be; we
never touch the page, but a 32-bit virtual address space does not just have
infinite pages to spare.

A jsapi-test exercises the new symbol allocation code. A few oddities in
jsapi-tests are fixed in passing.

Discussion after review led to some new assertions about minimum object size in
AllocateObject and AllocateNonObject.

js/src/jsatom.cpp

@@ -27,6 +27,7 @@
 #include "jsobjinlines.h"
 
 #include "vm/String-inl.h"
+#include "vm/Symbol-inl.h"
 
 using namespace js;
 using namespace js::gc;
@@ -380,6 +381,9 @@ AtomizeAndCopyChars(ExclusiveContext *cx, const CharT *tbchars, size_t length, I
 
     JSFlatString *flat = js_NewStringCopyN<NoGC>(cx, tbchars, length);
     if (!flat) {
+        // Grudgingly forgo last-ditch GC. The alternative would be to release
+        // the lock, manually GC here, and retry from the top. If you fix this,
+        // please also fix or comment the similar case in Symbol::new_.
         js_ReportOutOfMemory(cx);
         return nullptr;
     }