Re-organized directory structure and added testing framework.

Because this will be written in several languages, the package structure has been chaned to have a "lang" folder at the root. The only language at this time is JavaScript.

A testing framework has been added, RhinoUnit, and several tests have been added. Note: The tests are not hooked into the framework yet, so they will not work. Note: The LINT checker is throwing an exception. I am not sure what is causing it, but I have run the code against test scenarios locally and have not yet found a problem. Hopefully, hooking the tests into the testing framework will shine a greater light on what is wrong.
Added tests and builds.

The test definitions and data have been completed. The testing framework and tests have been built for JavaScript.

There is now a root build file as well as a build file for JavaScript that has two targets, "dist" and "clean". JavaScript has an additional target, "dist-min", which will minify the output JavaScript.
Updated the gitignore list.

Git will now ignore the "dist" directory at the root and at all of the sub-packages.
Fixed a bug in an error message.

An error message was not properly concatenating the entire error message.
Cleaned up ant's cleaning process.

The root directory's "dist" directory was not being deleted.
Formatting changes.

There were a few words misspelled. Also, JSON.stringify() was being passed its optional second and third arguments, but it was always being given null. These arguments have simply been removed.
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.
Added a copyright and cleaned up the code.

The project is now licensed under the Apache License 2.0 to the ohmage team.
Added the ability to reference schemas.

Schemas may now be composed of foreign schemas via the RFC draft for JSON References. In OOP terms, this allows schemas to be encapsulated and independantly developed and pulled into larger, more complex schemas, and it allows one schema to be extended ala inheritence.

Closes #2