Also include a 'clear filters' button (total hack).

Also try to pass params between GET/POST for better user experience.

add_terms() returns 400 if term does not exist and vocabulary is not
open

Replaced 'add_term' and 'add_free_terms' with 'add_terms'

It is now possible to add multiple terms to an item in the same
taxonomy via the REST API. Terms not already present in the database
will be created.

We got bad performance degrading as the number of terms increased.
Enabling django_debug_toolbar it was easy to see a bunch of queries
getting terms related to items duplicated as many times as items
in the system. Making the api view for listing items prefetch related
terms (and their taxonomies) removes these O(n) queries

If item does not exist

within a taxonomy

Allow filtering list of items by taxonomy term. The filter is build as <taxonomy_slug>:<term name>, so for example the following url filters on two terms (AND filtering): http://example.com/api/items?terms=taxonomy-one:a%20term&terms=taxonomy-two:another%20term . Note that taxonomy slugs cannot include colons, so no escaping is needed.

This is now not returning zero for items that fall outside the range.
This is probably not what we want.

`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

Now checks if taxonomy exists

Changed name from default 'pk' to 'slug' as that is what we are passing in to the API.

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

when adding to item

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

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