Move fileobject type definition to nameable complexType

xmllint fails to validate a schema where an embedded complexType
definition has a name attribute.  There is at least one reason one
would want to specifically reference the type definition of a
fileobject---embedding a copy of the file object, as in the (soon to be
proposed) differential annotations---so this definition is exported to
its own, name-able element.

Signed-off-by: Alex Nelson <a.nelson@prometheuscomputing.com>
Allow for extensibility in commonly-changing elements

The elements and attributes extended in this commit are the minimum
needed for differential annotations as idifference.py currently
generates, also allowing for other extensions on the dfxml root,
volumes, and fileobjects.

As it was written before this patch, the DFXML schema allowed for no
extensibility of elements, including from new namespaces.  To allow a
valid .dfxml file to include non-"dfxml:" namespaced elements and
attributes, the `<any>` element must be included in the `<element>`
definition.

To illustrate what this patch allows: If a modification timestamp is
changed on a file, to express that change in differentially-
annotated DFXML (under the "delta" namespace), idifference.py adds
these annotations:

    <fileobject delta:changed_properties="1">
      ...
      <mtime delta:changed_property="1">2013-09-19:01:23:45Z</mtime>
      ...
    </fileobject>

With the changes in this patch, dfxml.xsd will validate idifference.py's
extended-DFXML output.  To see for yourself, issuing these commands:

    git clone --branch=archive/delta_schema_v0 https://github.com/ajnelson/dfxml.git
    cd dfxml/python
    make check-validate

will ultimately give you this output:

    xmllint --noout --schema ../schema/delta.xsd idifference_test_formatted.dfxml
    idifference_test_formatted.dfxml validates
    xmllint --noout --schema ../deps/dfxml_schema/dfxml.xsd idifference_test_formatted.dfxml
    idifference_test_formatted.dfxml validates

Without the changes in this patch, any added element causes validation
to fail.  This goes against the spirit of XML extensibility.

A downside this patch illustrates is that every element and attribute
must be permitted to be extended.  Suggestions for alternative extension
mechanisms are welcome.

EDITS:
* 2013-09-23: Switched commit's validation example to archival permalink
* 2013-09-23: Added `<any>` extensions to `<dfxml>` definition

Signed-off-by: Alex Nelson <a.nelson@prometheuscomputing.com>
Do not require 'source' element

Some utilities, like hashdeep (md5deep, etc.) do not rely on a source
disk image.  For hashset generating utilities like this, relax the
source requirement.

Signed-off-by: Alex Nelson <a.nelson@prometheuscomputing.com>
Batch changes into v1.1.0rfc3

This updated RFC version introduces some allowances for DFXML
extensibility.  The schema's other-namespace parsing requirements are
set to "lax" to allow for arbitrary extensibility, in some elements.
Reporting the image source of the DFXML data is no longer required,
since hash sets (like those produced by `hashdeep`) don't necessarily
have a backing image.

Accepting these changes means the first official DFXML schema will
allow for extensibility of the language.

Signed-off-by: Alex Nelson <a.nelson@prometheuscomputing.com>
Merge pull request #9 from ajnelson/for_v1.1.0rfc3_seriesv1

For v1.1.0rfc3, patch series version 1

Acked-by: Mark Matienzo <mark.matienzo@gmail.com>