Add Schema object for data package management

This adds datapackage.schema which holds helper classes for
creating a data package schema according to the JSON table schema.
The classes this provides are Schema, Field, Constraints,
ForeignKey and Reference.

Each of these classes inherits from util.Specification which
provides an object like interface on top of a dictionary which
means that the dictionary is then ready for exporting to a
data package via a json serialization.
Subclass Resource from a dict and replace descriptor with self

This is a step in making Resource more like the Schema objects,
i.e. a dictionary object with special methods but ready for json
serialization as is instead of through a descriptor.
Convert Resource into a Specification object (dictionary)

This allows us to do validation on input if we want and the
resource can now be dropped into a json serialization since it is
already a dict. This mean resource no longer uses the descriptor
to hold its representation (it is the representation itself).

In addition, since Specification objects rely on a predetermined
dictionary of allowed keys and their types this will make it
easier to support multiple versions of the data package protocol.
Use Specification subclass' self instead of dict class methods

Calls like dict.__setitem__(self, 'data', value) are more verbose
and thus harder to read than simple self['data'] = value which
we can use instead. The Specification we inherit from isn't
overloading the dict methods. It's adding methods to the dict so
this is fine to do.
Migrate datapackage.licenses to the Specification inheritance model

This required different tests and moving helper function logic to
Resource (logic is duplicated as the DataPackage class uses the
helper functions to handle licenses and the DataPackage class does
not inherit from from the Specification class).

One test is skipped because that requires DataPackage license
functionality which isn't implemented.