Add extension points for defining new syntax

[thomaswilburn]

• Document the tokens that are currently parsed (https://github.com/nprapps/betty/blob/master/parser.js#L59), and add a way to pass in new token types (e.g., @key(filename.json), used to load content from an external file, would require us to add @, (, and ) as token types). The tokenizer will probably need to be a class instance and not a pure function for this to work.
• Add the ability to pass in additional parsing function and type tuples (https://github.com/nprapps/betty/blob/master/parser.js#L59) that will be called in the context of the parser class and have access to its stack manipulation methods. (e.g., [loadFileRef, "AT", "TEXT", "LEFT_PAREN", "TEXT", "RIGHT_PAREN"]).

Generally speaking, we shouldn't need to extend the syntax much as that's what the field name and value hooks are for. But it would be nice to have the option to be able to define new syntax without completely forking the code, and I think it's written in a clean enough way that we can do that solely through the tokenizer and parser.

The example above is not a great use case, but it does point out a real deficiency in the existing hooks, which is that they're processed without any real context of each other. There's no good way to define a new value type that mutates the field name on use (as the @key(file) syntax would do--otherwise you could just write @key: filename, but then you'd have a key with a sobachka in it instead of the key directly stored). New syntax offers us a way around that, as it provides ways for us to process the text before it reaches the hooks (which are called in the assembler stage).