Partial application initial development

No support yet for recursive partial applications; just a basic concept.
May now partially apply partial applications
f:arity extracted into its own stylesheet

It depends on partial application logic, but does not belong in partial.xsl
Error and hook for arity count in partial application
Apply test case ensures arguments are passed by reference

Confidence in its application is also increased through a unique node.
Partial applications apply target function when all params are bound

I am aware of the Saxon 9 warning regarding multiple imports of arity.xsl;
I'm going to choose to ignore this, formally in the future.  Each of the
stylesheets is treated like a module.

Michael Kay, Saxon's author, discusses it here:

  http://stackoverflow.com/a/10102298
f:make-ref, f:is-ref, and f:QName added
`f:apply' test case now using f:make-ref

That is, in place of manual construction.  This is especially important for
the next commit, which requires an arity datum.
`f:apply' currying support

Partial application support on all the other `f:apply' functions (other
arities) will be completed in the next commit.
All `f:apply' functions support partial application

'Tis tasty!
README.md updated with mention of partial applications

It does not do it much justice; documentation will come later.  The test
cases are comprehensive.
apply-gen TODOs added to header
Partial dynamic function applications

This introduces support for partial applications on dynamic functions.
The test cases are comprehensive and the implementation should be
quite stable.

Even though the base higher-order function implementation was based on
the work of Dimitre Novatchev[0], I have chosen a different route for
partial application:  Novatchev's method relies on storing partially
applied arguments as nodes, together with their types.  The types are
detected the best they can be, with accuracy varying wildly depending
on whether a schema-aware processor is present.

But regardless, that method would not retain node context.

Sequences, however, do.  By using sequences, we allow the processor to
retain all type and context information perfectly without any
additional work that is inaccurate, adds complexity, and likely to
cause subtle problems.  It will also support any types that we are
unaware of.  As Novatchev mentions:

  The argument type-detection that f:curry() uses has been implemented
  only for the builtin XML Schema datatypes. It will not recognize the
  user-defined type of an argument, which can be created by an user of
  a Schema-Aware (SA) XSLT 2.0 processor.[0]

This is not a problem with hoxsl.

[0]: http://conferences.idealliance.org/extreme/html/2006/Novatchev01/EML2006Novatchev01.html