Do event tracking for major forum events.

This PR is intended to supersede #4840 . Please close that one and continue the discussion here.

This PR is a WIP because the specification provided at https://openedx.atlassian.net/wiki/pages/viewpage.action?spaceKey=AN&title=Forum+Events has left me with a few questions, and I'm not sure that this implementation conforms entirely to the vision of what was stated. Most of it has been implemented.

The tests are also currently failing because tests which test the comment functionality did not anticipate the thread ID needing to be accessed, but these events now require it, so those tests will need patching to permit this. I also added a few new tests which will need similar fixing. But I'd rather start getting feedback now.

A few issues:

1. How would one get the category id and name? I'm not really sure what these are to begin with, as I don't see them as fields on the comments.
2. How would one get the origin? It doesn't seem like there's a sane way to do that at the moment. Would there need to be modification to the existing views to post the enum value we want? Would there be any values other than 'courseware' and 'forum'?
3. Some of the keys in the spec appear oddly inconsistent, though I may be missing something. For example: 'discussion.id' vs 'category_id'.

Feedback would be appreciated. Thank you.

* Partner information: 3rd party-hosted open edX instance, for an edX solutions client (so will need to get some sort of solution merged in)
* Merge deadline: Oct 22nd (soft requirement to minimize code drift, we maintain it on the client fork in the meantime)

Ping @sarina 
My apologies, I should have thought more deeply about what you're doing here. I'd actually prefer you simply mock the "emit" call and validate that it is called with the correct arguments. I'm OK making that change myself after you commit if you don't have time since I failed to notice this in the first pass.

We do some fussing around with the event after "emit" is called and I'd rather this test logic is not dependent on the internals of the event tracking library and the event processing pipeline.