DFInitOnce: Avoid dependency on pthread/windows.h

Previously, we needed to include pthread.h so that the pthread_once_t
type would be defined, which the compiler would use to determine how
much storage to allocate for a one-time initialisation control variable
(e.g. as used in DFNameMap.c). However, we want to avoid having to
include this header file directly or indirectly in any code outside the
platform module.

To get around this requirement, we now implement a custom one-time
execution function in DFInitOnce. We define the DFOnce type (previously
corresponding to pthread_once_t) as int, and DF_ONCE_INIT (previously
PTHREAD_ONCE_INIT) as 0. In Unix.c (as well as Win32.c) we use a mutex
to control access to the int variable, so we can ensure the test and set
happens atomically, allowing us to guarantee that the function executes
only once.
Move DFErrorSetWin32 to Win32.c

This function was previously prototyped in DFError.h, which required
inclusion of <windows.h> (via DFTypes.h) in order for the DWORD type to
be recognised. To avoid having to include <windows.h> indirectly in all
header files, and because this function is only actually used in
Win32.c, move it there instead.
Fix unused label warning
Move system includes out of DFCommon.h

Instead, only include system headers in C source files.

We still have a few bits and pieces in DFCommon.h to paper over platform
differences. For windows, we need to define snprintf and strasecmp to
their windows equivalents (_snprintf and _stricmp). And the S_ISDIR
macro is missing on Windows so that is still there, but we can probably
use the replacement instead since it's only needed in a couple of
places.

Ideally we want to avoid all #ifdef WIN32 everywhere, and abstract that
in the platform layer. Currently however we need to include <direct.h>
(windows) and <unistd.h> (Unix) in a couple of places since certain
functions like rmdir are defined in different headers in the two
platforms. I'm not sure what the best way to deal with this is, in the
absence of including those in DFCommon.h, but this is only in a handful
of places within the code right now.
Add editing code from UX Write
Remove old DocFormats.h header

This header was only used by UX Write. It used Objective C #import
statements and exposed far too much stuff. We'll replace this with new,
clean API header(s) in due course.
Beginnings of a proper API

First step towards defining a clean public API that exposes only the
necessary functionality. Currently we have the following three
functions:

DFGetFile - Converts a .docx file to a .html file.

DFPutFile - Updates an existing .docx file from a modified .html file

DFCreateFile - Creates a new .docx file from a .html file

Eventually these will be expanded to support other file formats as they
are incorporated into the library. The actual conversion functionality
is in the generateHTML and updateFrom functions, taken directly from
dfutil. Now, dfutil calls these public API functions instead of access
internal classes.

These function represent the simplest use cases of the library only;
namely conversion between different formats. They do not yet provide for
access to the structure of the document in its intermediate form.

We adopt the convention that the public APIs can be used from a consumer
by adding the following include:

    #include <DocFormats/DocFormats.h>
Rename DFStore to DFPackage

'Package' is a more suitable term for this class, as is refers to the
idea of a collection of files stored in some packaging format (which
could be a zip file, directory, or memory). It also corresponds to the
terminology used in both the ODF and OOXML specs.

In cases where we use a class like WordPackage, which operates at a
higher level of abstraction, in conjunction with a DFPackage object, we
refer to the latter as a "raw" package, in the sense that it just
provides storage capabilities without any semantic functionality.
Merge pull request #1 from uxproductivity/develop

I just want to sync