feature/analytics

**Synopsis**
This PR implements basic analytics in flashcards for tracking and measuring learner events. The events are recorded in the form of statements structured as noun/verb/object which may include  additional context in order to understand it. The kinds of activities that we can track include:

* When a learner launches flashcards as an LTI tool.
* When a learner accesses a collection.
* When a learner accesses a deck of flashcards.
* When a learner quizzes themself on a deck of flashcards.
* When a learner reviews a deck of flashcards.
* When a learner downloads a deck.

I think tracking events on the client side should be out of scope for this pull request. For example, we might want to track how long a learner spends on a given deck or card; the rate at which they review a deck; how many cards they quiz themselves on; whether they use fullscreen, play, or shuffle functionality, etc. Once the basic framework is completed on the backend, we can add an API endpoint and hooks on the client side to gather that information.

**Questions:**
* Do we care about tracking instructor activities? If so, what kinds of instructor activities are meaningful to track?
* Are there any learner activities above that are missing or aren't meaningful?

**Proposed Implementation**
The proposed implementation will consist of the following components:

1. Python module `flash.analytics` with a function `track(actor="", verb="", object="")` that can be called from views or other sections of the app to record learner events.
2. Django model `flash.models.FlashAnalytics` that will be used to store and query events. This will be a mysql table with the following schema:

```text
ID -- primary key
STMT_ID -- A UUID (Universally Unique IDentifier).
STMT_ACTOR -- "<I> did this" (should reference user object)
STMT_VERB -- "I <did> this" (string)
STMT_OBJECT -- "I did <this>" (string)
STMT_CONTEXT -- "I did this <context>" (serialized json string). Optional context that might be helpful to understand the rest of the statement.
STMT_STORED -- The time at which the statement is stored (timestamp).
STMT_TIMESTAMP -- The time at which the experience described by the statement occurred (may differ from STMT_STORED).
```

Note: The above schema is loosely based on the [tincan](http://tincanapi.com/) framework and [spec](https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md). It's different, but hopefully similar enough that it can be adapted later if needed.

@jazahn Can you review this proposal?

---
[FLASH-193](https://jira.huit.harvard.edu/browse/FLASH-193)
The UUID doesn't serve a purpose at the moment. The primary key is sufficient to uniquely identify the analytics data in our system. This is more of a future-proof thing such as when we want to expose data to external researchers and make the data easily transferrable to other systems. We'll keep our ID private and only expose the UUID, which should be universally unique. It's mentioned in the TinCan API [spec](http://www.adlnet.gov/wp-content/uploads/2013/05/20130521_xAPI_v1.0.0-FINAL-correx.pdf) and [this deep dive](http://tincanapi.com/2013/08/22/deep-dive-roundup/). But perhaps YAGNI (you ain't gonna need it) applies here. We could always add it later.