Move licenses and sources code into their own files
Start working on a generic resource object
Add tests for getting/setting resource data
Add tests for getting/setting resource paths
Add tests for getting/setting resource url
Add name setter and related tests
Add format setter and related tests
Add setter for mediatype and associated tests
Add encoding setter and tests
Add methods for guessing the resource format and mediatype
Add some tests for computing the size of the data
Write more tests for computing the data size
Handle cases where the datapackage uri is a url
Return helper function for getting the file size from a url
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.
Migrate datapackage.sources to the Specification inheritance model

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

This also called for two breaking changes.

* Previous version required name for a source. This restriction
  does not comply with the specification and has been removed.
* Because the name requirement has been removed it is no longer
  possible to remove sources based on names so that method has
  been removed and removing is left up to users.