Predefined literals are problematic from a Jsep using developer POV

[craigphicks]

This post concerns the predefined literal reserved words. That is expressions with type==="Literal" and for which the value is set by the parser directly from the hard coded table

literals = {
			'true': true,
			'false': false,
			'null': null
		},  

Problems wit the current setup:

1. There is no interface to discover or alter these reserved keywords.
2. The content is arbitrary - e.g. null is a member while undefined isn't.
3. It's very opinionated. There is no reason to suppose null should be a reserved word in the developers context. Or that true and false, if reserved, should be all lower case.
4. It forces the developer to consider extra logic to prevent these keywords from being used as identifiers. Needlessly.
5. Instead of these reserved works getting categorized as type==="Identifier" with a flag for reserved and areservedValue field, they are parsed as type=="Literal", sharing the type "Literal" with raw strings and numbers. This could be anti-intuitive to many developers, because if those reserved words were not specially parsed by Jsep, they would end in the case for type==="Identifier" where the developer would have their own simple table of reserved words for pre-emptive lookup - simple and straightforward.
6. There is no warning about any of this in the documentation.

Mostly Jsep just works as a developer would expect - which is wonderful and the documentation is not missed (that much). But this is an exception. And actually this is also an exception (or could throw one) and could be included here too - please forgive my poor attempt at humor.

[craigphicks]

It was easy enough to recast the unexpected "Literals" as "Identifiers" at the top level of the interpreter function.