The indication of specific characters in the source code that are in
error is not yet implemented, but this gets at the main functionality
of printing diagnostics.
Although the actual parsing code will be split across multiple packages,
it's convenient for the public interface to be in a single package. The
parsers are accessed through a "Parser" type, which both wraps the
real parsers and maintains a registry of parsed files to ensure that
the same file isn't parsed more than once (which might be confusing if
there are different results) and to provide raw source code for
diagnostic-printing functions.
The parser API is in a separate package both due to the fundamental
problem that it would create an import cycle if included in the main
package and also because it's expected that calling applications will
deal with parsing once in a central place (a single file depending on
zclparse) but the resulting objects will be used broadly across the
application, causing many files to depend on the main zcl package.
Some applications treat an entire directory as a configuration, merging
the configurations from all of the files in a directory and treating them
as one.
MergeFiles supports this idea by wrapping the bodies of the several files.
It's not yet implemented here, but once implemented it will act as an
aggregator of the content of the wrapped bodies, delegating to them for
actual body content and then merging the returned body content in a
well-defined way.
The term "element" is already used for an item from a collection in cty,
so we'll use "block" to talk about the nested blocks in a zcl config to
reduce confusion.
Currently lacking correct support for unicode text segmentation into
grapheme clusters, so it miscounts "Column" in positions. This will be
addressed later.
