Provide get, put, and create commands in dfutil

Replace the default action of dfutil from determining which type of
conversion should take place based on file extensions/existence, and
require the user to explicitly specify the action to be performed. These
are:

dfutil get concrete.docx abstract.html

    Create a new HTML file from a Word document. The HTML file must not
    already exist.

dfutil put concrete.docx abstract.html

    Update an existing Word document based on a modified HTML file. The
    Word document must already exist, and must be same document from
    which the HTML file was originally generated.

    The put operation cannot be executed twice on the same Word
    document, because after the first time, the fact that the document
    is modified will mean that the ids become out of sync with the HTML
    file.  If you want to update a document multiple times, you must
    create a copy of the .docx file each time, and update that.

dfutil create concrete.docx abstract.html

    Create a new Word document from a HTML file. The Word document must
    not already exist.
Implement DFGet, DFPut, and DFCreate

These three functions implement the top-level entry points to the key
bidirectional transformation operations on documents. Compared to the
DF{Get,Put,Create}File functions, they allow for more custom usage.
Instead of requiring the concrete and abstract documents to be stored in
a file, they can be stored in various other means, as supported by the
DFConcreteDocument and DFAbstractDocument class.

One example of where you might want to avoid filesystem storage of
documents is when creating an abstract document purely for the purposes
of making some changes to it and then doing a put operation to update
the original. Where it was previously necessary to create a temporary
file for the conversion, it can now be done entirely in memory, using
packages created by DFPackageNewMemory().

Another example is the automated tests, which create an in-memory
representation of a document based on a plain text format, and avoid
writing temporary files to disk during test runs. While these functions
presently still call the Word-specific conversion functions directly,
they will shortly be modified to use DFGet, DFPut, and DFCreate.

The DFGetFile, DFPutFile, and DFCreateFile are now wrappers around their
more generic counterparts. They construct a DFConcreteDocument and
DFAbstractDocument, and then pass those to the wrapped functions. They
can be considered a useful illustration of how to use the API, in that
they operate at a higher level of abstraction, but are done entirely in
terms of the lower level of abstraction of DFGet, DFPut, and DFCreate.

We also now have the basic infrastructure in place for easily handling
different concrete document formats. There is a switch statement in each
of these formats which checks which format the document is stored in,
and then dispatches to a get, put, or create function specific to that
format. Currently the only supported format is .docx, but others can be
added by implementing versions of these functions and adding them to the
switch statements. We may even choose use an "interface" (in C, a struct
containing function pointers) to record the implementations of these
operations for each supported file format.