Rework `.`-macro to support computed member exprs, remove `get`.

[anko]

Details in a0fa525. Fixes #13. Breaks API, so would be a minor-version bump.

@tabatkins :+1:?

[anko]

Still needs appropriate changes to docs and doc-tests before merge, but this is what it would functionally look like.

[anko]

Some relevant gitter chat about this here and here.

[anko]

Having played with this for a while, I'm having second thoughts. I'll summarise.

Points in favour:

• Currently, (. a "hi") compiles to a['hi'];. One might reasonably expect that the literal "hi" can be replaced with an identifier containing the same value, like (. a b), but that currently compiles to a.b;, which has a different meaning. This is confusing.
• This change means we would need 1 less macro, because get could go.

Points against:

• If (. a "b") compiles to a.b;, then how do you get a["b"];? (And vice-versa.) The distinction matters. JavaScript has two constructs for member expressions; . for static and [] for computed, so we're losing generality.
• Static property access is by far more common than computed. Though sugar is available, writing (. Array "prototype" "slice" "call") to produce Array.prototype.slice.call; is quite grating compared to the current (. Array property slice call).

[anko]

After much further deliberation detailed in the above comment and the original issue #13's closing comments here, I've concluded that these changes are unworkable.

If the described behaviour is of particular importance for some use-case, it could be implemented by a user macro.