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)
Curious as to why we need a separate UUID in addition to the primary key. Can they not be one and the same?