3.0: Simplify ivars

[iccir]

Currently, we mimic Objective-C's "the same name can refer to multiple ivars". For example:

@class TheSuperclass {
    _foo : String;
}
@end

@class TheSubclass : TheSuperclass {
    _foo : String;
}
@end

In the above, _foo can either refer to TheSubclass's ivar (currently $oj_i_TheSubclass$_foo) or TheSuperclass's ivar (currently $oj_i_TheSuperclass$_foo), depending on where you use _foo.

This is something that we've never gotten right (#127), and it's also a confusing behavior of Objective-C. Worse, it makes debugging difficult due to including the class name inside of the backing JavaScript variable.

We should reevaluate for NilScript 3.

[iccir]

My current thought process:

1. If a subclass declares the same ivar name as a superclass, error.
2. If a subclass declares a property which conflicts with a superclass' ivar, @dynamic must be used to show intent. @synthesize foo=_foo may also be used (or maybe it should error?).
3. Ivars are considered protected and can be accessed in subclasses and categories (oj 2 allowed category access, contrary to Obj-C).
4. We should have a wiki page, README section, or .md file which documents these types of differences between Obj-C and NilScript.

[iccir]

2 should produce a warning, as @jmarr uses @synthesize foo=mFoo for his ivars.

[iccir]

Here's the updated spec:

1. If a subclass declares the same ivar name as a superclass, error.
2. If a subclass declares a property which conflicts with a superclass ivar, @dynamic must be used to show intent. If a subclass declares a property which uses a superclass ivar via @synthesize, warn (this is the same as in 2.x)
3. Ivars are considered protected and can be accessed in subclasses and categories (oj 2 allowed category access, contrary to Obj-C). A new warn-inherited-ivars compiler option will warn if an inherited ivar is used directly.

[iccir]

Oops, I forgot to add information about the new --simple-ivars compiler flag. When set, the NilScript compiler will use 'this._foo' to refer to the '_foo' ivar, rather than 'this.N$_i__foo'. This should make debugging easier.

Per the documentation:

As long as ivars are prefixed (either the default _theIvarName or the non-standard prefixes such as m_theIvarName or mTheIvarName), this should be safe. You may run into issues if you use this flag and also use an ivar name which conflicts with an Object.prototype property. Examples include: constructor, hasOwnProperty, toString, valueOf, etc.

--simple-ivars has no effect when the squeezer is enabled.