Add passingt est for adding a Term to an Item
Add unicode methods for Taxonomy and Term
Change the unique contstraints for Term so that
Term name needs be unique only for a given Taxonomy

Removed taxonomy and term classes from data_layer - just reference the ones
in taxonomies app directly for now.

Will need to run "deploy/tasks.py clean_db" and "deploy/tasks.py update_db"

Ive been working through some options for how the REST
api will work with categories in the readme file.

The last error from running the tests was that the TErm table didnt
exist in the test database. So I'm running

    manage.py makemigrations

And it fails with

    AttributeError: 'NoneType' object has no attribute 'unique'

Following the [django docs](https://docs.djangoproject.com/en/1.8/topics/db/models/#abstract-related-name)
I put in:

        related_name="%(app_label)s_%(class)s_term"

But still can't even get a helpful error message.

Tidy up transport delete items

Make the url generation work proerly (though I'm fairly sure we don't
actually need the url as an argument to delete) and remove
debug print statement *blush*

Make bulk_delete use delete() instead of bulk delete from REST

hid expects the 'dashboard' reverse url to point to the index page - so leave it that way. Added an initial dashboard called 'main' as that is execpted to exist, and tests require it.

ItemTransport clas --> transport.items module

Implement a dashboard infrastructure to allow us to register widget types, create dashboards, create instances of widget types with specific configuration and associate those with a given dashboard, at a given position. The dashboard infrastructure is moved out of hid and into it's own application as it is stand alone (the widgets may depend on hid specific logic, but the infrastructure doesn't).

Replace with ItemTransport object, which needs to be instantiated. I
think it can be reused between calls to its methods so there's no need
to create new ones all over the place, but that's what I have done so
far. I'm a bit uncertain about module level variables, and not
everything is contained in a class.

These are no longer used by transport, and nobody else should be using
them.

Actualy they are now also a class.
The existing functions still exist and call into the class
(wastefully creating an instance every time but I expect these
to go away and rewrite the clients to use an instance of the
transport class directly.

By default the router derives the url names from
the model name (which it gets from the queryset)
which is Message

Note: transport still uses the explicit views