Add tests for $ion_literal.

[toddjonker]

Description of changes:
This isn't documented in the spec (see amazon-ion/ion-docs#322) but this reflects my understanding of the intended behavior.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[popematt]

Any IVM-like symbol with an annotation is already always a symbol, and doesn't need an annotation, right?

Also, how does this affect text Ion—specifically, a quoted, unannotated IVM is actually a no-op. Does resolving $ion_literal happen before or after determining whether it's a no-op?

[toddjonker]

Any IVM-like symbol with an annotation is already always a symbol, and doesn't need an annotation, right?

True, but that doesn't help when you want to represent the unannotated symbol with text "$ion_1_0".

Does resolving $ion_literal happen before or after determining whether it's a no-op?

They would have to happen at the same phase. That no-op behavior of (eg) '$ion_1_0' means that either:

1. the token is absorbed/discarded at the parsing level, as if it were a comment; or
2. the parser emits it as some new kind of syntactic entity (AST node type), to be discarded by the expansion phase; or
3. the parser emits it as a normal symbol, and the expansion phase discards it (at the same it would've detected any $ion_literal annotation).

I think (1) would be easiest to implement but surprising in terms of round-tripping. (2) is obnoxious. So I'm inclined to go with (2) above as a clearer specification of the 1.0 handling.

For 1.1 I currently think we should dump the no-op behavior of such quoted forms, making them normal symbols; let the unquoted form be "escaped" via $ion_literal, and do the same thing for local symtabs $ion_literal::$ion_symbol_table::{. The outcome is that Ion 1.1 allows everything in the data model to be written at top level as user data.

It wouldn't surprise me if Ion 1.0 implementations are full of bugs in their handling of this space. We didn't think it through carefully enough, and then back-filled specification years later to try to match the observed behavior of the primary implementations.

This is worth a separate issue, especially since it's not even covered by this CR. 😉