This makes it more efficeint for `Item.apply_term` to use `term.taxonomy`
because the taxonomy object is selected Along with the term.
I suspect it will be generally useful to do this because we want to
think of the taxonomy details as part of the definitino of each term.

`Term.objects.by_taxonomy()` should propbably do `select_related()` to get the term back as well, see where used in `api.add_term`
https://trello.com/c/fWrvZDau/77-clear-out-technical-debt-from-working-on-taxonomies

`add_term` in api views should return json of the serialized version of the new item -- currently empty dict

https://trello.com/c/fWrvZDau/77-clear-out-technical-debt-from-working-on-taxonomies

Add tests for what happens when `add_categories` gets called with nonsense items and category names, should fail gracefully
https://trello.com/c/fWrvZDau/77-clear-out-technical-debt-from-working-on-taxonomies

Also added test intended to illustrate why I included the test for
is_optional

The Data Layer apps need to prceed the local ones because of
dependencies, the app can depend on the data layer and imports
them before they have been initialised

Changed the factories not to create objects if they already exist.
Also renamed various test data to have names that don't conflict with
the fixtures,

Fix previous merge: use the version of get_category_options that came from the taxonomies branch, not the staging branch.

Still hard coded
https://trello.com/c/GSjVYcNz/76-change-hardcoded-drop-down-elements-on-staging

Interlally it was using add_term which did just what its name said:
it add a term for the item. There was no check that you could only
have one if the thing was a category. So I added a rudimentary support
for that and creted some more test debt. (list copied in below in case
it gets lost)

Then added the apply_term method on Item (see note about how it sucks
for this to be there) which checks the multiplicity of the taxonomy
of the incoming term and acts apporporately. Finally all taxonomies
currently say they are have optional multiplicity (i.e. categories)
whichi s fine for the question type story.

- [ ] Add tests for data_layer.models.Item.apply_Term
- [ ] refactor tests in rest api to use the api
- [ ] Are the updates to the model tags being saved and output okay? Why does that fail?
- [ ] hid/views/add_Categories should only update category if it has actually changed
- [ ] Test add_Categories (in the hid view) with multiple id/term pairs?
- [ ] Add error reporting to the bit of View/Edit screen that adds categories to items.
- [ ] Add tests for adding categories to more than one item at once via browser
- [ ] We probably need a default value in the category selector to show  that there's initailly no value selected
- [ ] Add tests for what happens when add_categories gets called with nonsense items and category names, should fail gracefully
- [ ] Add transport wrappers for listing the terms in a taxonomy, and update View/Editr screen to use these in place of modls directly
- [ ] Add transport wrappers for creating taxnonmies and terms
- [ ] add_Term in api views should retrn json of the serialized version of the new item -- currently empty dict
- [ ] Term.objects.by_taxonomy() should propbably do select related to get the term back as well, seewhere used in api.add_term

I think the version of the models you get for migrations doesn't include
the methods we defined, so the save method doesn't set slug
from name. So I have added explicit name and made the old
name, which was in slug format, into the value of slug.

Refactor the code to handle file input type (use a custom button, and automatically submit upon file selection) so that it can be used on multiple pages. Add an upload button on the view/edit page.

Use accessor to fetch out the name of the first term
(assuming there will be at most one)

And the get_category function isn't needed any more
because its the shrot name that gets compared in the template
to decide which is selected.

Categories on the view/edit screen no longer have hard coded values
but instead read the available terms from the database

Add add categories method to hid/views and call from process items

Has a test, but so far only for the single category case.

add_term now throws TransportException if term does not exist

when adding to item

Throws exception if important fields are missing.

To create "tagged" items with terms
to add tags to items via the api