Add @accessor support to class_addIvar.

In preparation for the new parser/compiler, I have beefed up class_addIvar to support accessor generation. This is in contrast to how we currently handle accessor generation by actually inserting setter/getter code into the resultant javascript output.

Instead, class_addIvar will now support a new fourth parameter describing the accessors that should be supported. The fourth parameter is a JS object with the following (optional) properties:

{
"getter": __string_name_of_getter_method__,
"setter": __string_name_of_setter_method__,
"copy" : __true_or_false_or_absent__
}

For example:

class_addIvar(CPView, "_subviews", "CPArray", { "getter": "subviews", "setter": "setSubviews:", "copy":true });

class_addIvar will then internally generate the methods and add them using class_addMethod. There are a few reasons for this:

1. If we ever decide to change the behavior of accessor generation, this will avoid different frameworks having "stale" versions of getter/setters. For example, right now we only pay attention to "copy" with setters. I think its worth considering also returning a copy for getters. With our current implementation, this change would require recompiling the world.
2. Smaller resultant code. Accessor code is completely redundant, yet has the potential to be a significant portion of what we push over the wire if we start using it in ernest. There is no reason for this when we can describe it much more concisely.
3. This allows for easier dynamic setter/getter generation if you are making a class at runtime.
4. This is closer to how properties work in ObjC (class_addProperty)

However, the main impetus behind this was to allow for line code parity with the new parser/compiler. What this means is that every line of generated code is guaranteed to be on the same line as the original code. This means if you get a runtime error on line 56, you can be sure to look at the same code in your original code files. This is helpful in environments where we won't have source maps. Everything else was being generated on the same line, except for the fact that all the ivars were being bunched up together with class_addIvar*s* and all the generated methods. This allows us to inline the class_addIvar, and not require any additional code (thus offsetting anything after it) for accessors. After the transition is complete, we should deprecate class_addIvar*s* (and class_addMethod*s*).