Added definition and data extensions.

The hooks to allow someone to add extensions to type definitions and data validation are now in place. To add an extension, modify the prototype of Concordia by setting a field of the form `validate(Schema | Data)Extension{TYPE}` to a function that will perform the type or data validation. For example, the following will extend Concordia to call the "validateNumberType(obj)" function when validating a number type's definition:

    Concordia.prototype.validateSchemaExtensionNumber = validateNumberType;

The following will assign a function, "validateStringData(schema, data)", that is designed to validate string data:

    Concordia.prototype.validateDataExtensionString = validateStringData;

Both of these can be removed from Concordia by executing the following two instructions:

    delete Concordia.prototype.validateSchemaExtensionNumber;
    delete Concordia.prototype.validateDataExtensionString;

A type validator function will take one parameter which is the specific object within the schema that is of that type. For example, take the following definition:

    {
      "type":"object",
      "schema":[
        {
          "name":"myNumber",
          "doc":"A number field with a comment and an extended field.",
          "type":"number",
          "customField":"foo"
        },
        {
          "name":"myString",
          "type":"string"
        }
      ]
    }

The function "validateSchemaExtensionNumber(obj)" would receive, for its "obj" parameter, the JSON object:

    {
      "name":"myNumber",
      "doc":"A number field with a comment and an extended field.",
      "type":"number",
      "customField":"foo"
    }

It could then, presumably, do something with the additional field to validate that it follows some convention that will later be relied upon when validating data. Of course, there is no need to use this extra field; however, type extensions are designed with this purpose in mind.

A valid data point for this schema would be:

    {
      "myNumber":123,
      "myString":"bar"
    }

A data validator receives two arguments. The first, "schema", is the portion of the schema that relates to the data being validated. The second, "data", is the value of the data being validated. For our example, the data validator is validating string fields, so the "schema" given to the validation function would be:

    {
      "name":"myString",
      "type":"string"
    }

The "data" would be:

    "bar"

We are only given the data of the entity being validated, so we do not get the entire object or its context. However, this can be inferred through the corresponding "schema" parameter.

It is likely that type and data validators will be used in conjunction; in other words, an extender would write both a type and data validator for the same type where the type validator would ensure that some type extension, e.g. "min" and/or "max" fields for the number type, is logical, e.g. the values of the "min" and "max" fields is a number, and the data validator would ensure that all data conformed to those type restrictions, e.g. that data corresponding to a number schema that included a "min" property was greater than (or equal to) the "min" field's value.