Betterify property access, implement ES5 getters and ES6 syntax for objects

[dead-claudia]

@anko

Fixes #13, #23, #22.

This intentionally reserves generators, because those haven't been
implemented in functions yet. It will be easy to add when they are
implemented elsewhere, though.

It also is based on @tabatkins' idea of using :keyword to refer to symbols rather than simple atoms.

Note that this can change depending on the outcome of anko/sexpr-plus#3, as it would allow for a better integration into the syntax level (and also to help decouple the standard library a little). That modification would also, IMHO, be a little less fragile, and it's almost trivial to convert my patch to use that version if implemented. Matter of fact, that would actually simplify it, as I'm checking just types rather than a type and the first character.

And, well, a single quote looks better. 😄 But as it stands, this is a WIP until anko/sexpr-plus#3 is addressed

[dead-claudia]

Also, this shouldn't be merged before #40 and #42 are.

[dead-claudia]

This latest push is still part of a WIP.

[dead-claudia]

Just realized...this will also fix #22.

[dead-claudia]

Here's a summary of some of the changes to the syntax:

1. (. foo bar) now compiles to foo[bar]. (. foo :bar) compiles to foo.bar. The rest is still the same.
2. Object getters and setters can be specified with (object (get :foo () (return 1))) and (object (set :foo (x) (= _x x))).
3. ES6 methods are specified with (object (:foo () (return 1))). That compiles to {foo() { return 1 }}.
4. ES6 computed keys are specified with (object ((key) "value")). That compiles to {[key()]: "value"}.
5. Regular keys are now this: (object (:foo bar)). The old syntax of (object foo bar) will fail to compile.
6. String literal keys are now this: (object ("foo" bar)). The old syntax of (object "foo" bar) will fail to compile.

[dead-claudia]

@anko

I know this is currently broken, but could I get some ideas on why the macro with a require'd object argument is mysteriously not passing, despite normal modules doing the contrary? This is the offending test. I know it's a regression, but I can't seem to figure out even where to start looking for it. 😦

If this is any help, the (macro) macro itself isn't even calling the builtin macro implementation (which involve only minor changes to use this instead of an assigned env), much less the object macro I practically rewrote. I've figured out that much.

[dead-claudia]

Even weirder about this is the fact this is only happening locally. I'm looking into it on my end.

[dead-claudia]

Never mind about that. It's not broken. I just had to replace my node_modules folder.

[dead-claudia]

@anko I think this is ready to merge now.