Clarify transcoding capabilities and requirements

One fundamental capability of Ion 1.0 is that any document can be transcoded between text and binary without access to any shared symbol tables, even without evaluating local symbol table directives. For the moment, I'll call this capability "standalone transcoding" since the document is all that's needed to support transcoding.

Note that this encompasses the basic case of pretty-printing a binary document for human consumption; any Ion 1.0 binary document can be pretty-printed as text in a standalone fashion. It might be full of SIDs, but it's structurally accurate.

It's recently become clear that 1.1 has broken this capability:

E-expressions cannot be parsed from or written to binary without access to the module that defines them. If imported from a shared module, that module must be accessible before a single byte of the E-expression's body can be produced or consumed.
- The above applies recursively through macro-shaped parameters.
Any consumption of a document requires top-level E-expressions to be expanded at least to the point of determining whether any output values are directives.
Wherever a macro_table (either in a directive or a module) exports a full module by-name, eg (macro_table SomeModule), that module must be available in order to determine the number of addresses to allocate.

Since the binary pretty-printing has long been a significant part of Ion's elevator pitch, I think we need to have a clear story here. At the very least, we should work through the encoding conditions required to enable things like standalone transcoding and pretty-printing, so we can advise users what to do or avoid if they want their documents to retain that property.

@tgregg (I think) suggested that we add a distinct directive syntax that guarantees the document (or at least the segment) supports desirable transcoding properties without access to shared modules, and I think that's a very good idea.

amazon-ion / ion-docs

Clarify transcoding capabilities and requirements #311