Refactor type generator

The core of this is changing stuff like `&byteArrayBody(t, className(t, methodClass(t, method)), 0)` to `method->class_()->name()->body().begin()`.  Many things that were previously just 'object's are now statically typed; this uncovered a couple genuine bugs and many oddities:
* VMClass.staticTable was previously being used as either a Singleton (for the real static table), or for array classes, a Class (representing the array element class).  I Added a arrayElementClass field for this.
* Code.pool was previously either the constant pool or (for compiled methods) the stack map.  I added a stackMap field for this purpose.
* Processor::makeClass had it's "addendum" and "staticTable" argument names swapped - but they were actually being passed to the final constructor in the right order.
* Code.exceptionTable is either a `short[]` or an ExceptionHandlerTable (I left this uncorrected).

Bugs found:
* Improper resizing in growArray (fixed) - see the fixed version: https://github.com/joshuawarner32/avian/blob/b82ef0d3e8f715b8040422a8b4e5f81654f2e8bb/src/util.cpp#L549 vs the old version (note lack of ` * BytesPerWord`): https://github.com/ReadyTalk/avian/blob/master/src/util.cpp#L559
* Where a type-checking assert would have triggered should it ever have been executed (unfixed, as of yet): https://github.com/joshuawarner32/avian/blob/b82ef0d3e8f715b8040422a8b4e5f81654f2e8bb/src/classpath-android.cpp#L1184

Other minor changes:
* We no longer add padding on super-class boundaries.  This makes the algorithm for computing field layouts simpler, since it doesn't need to know about these boundaries.
* type-generator now uses lots of c++ standard library code.  This is not part of the VM, and thus we don't have to worry about linking libstdc++ with the VM.
* `assert` as been renamed to `assertT` ("assert with Thread context") to avoid a conflict when including both avian headers and the standard <assert> header.

I also waited until the end before reformatting code that I changed (using git-clang-format).

@dicej, I took the liberty of doing a bulk, global reformat with clang-format at the end.  I can remove this commit if you object.
There are a few bits of commented-out code that will no longer work without modification when uncommented.  That's the problem with commented-out (or #if 0'd) code, I guess -- the compiler can't help you.  In the future, we should probably change all the commented-out code to be wrapped in (non-preprocessor) conditions so we don't have problems like this.