Overhaul Segment.io integration

The changes contained herein aim 1) to fix the persistent issues we've had in the past with our business intelligence analytics and 2) set us on a path towards gathering correct and useful information in a way which interfaces third-party services with our internal eventing infrastructure. Here's a quick breakdown of what I've done:

- Use Segment.io's alias and identify methods to correctly **join user histories in Mixpanel**
- Report **new events** corresponding to **account registrations**, **sign-ins**, **course enrollments**, **course unenrollments**, enrollment **mode changes**, and enrollment **mode upgrades**, each with appropriate properties attached to indicate user actions (e.g., registering or signing-in to enroll in a course)
  - These new events are designed to accompany the upcoming functionality change related to enrollment and track selection (i.e., enroll immediately on click of the "Register" button)
- ~~Remove page view events like "Viewed Dashboard Page" and "Viewed Register Page" currently being sent to Mixpanel~~
- Name events in accordance with the Analytics team's [event naming convention](http://edx.readthedocs.org/projects/userdocs/en/latest/analytics.html#naming-events)
- Where possible, roll Segment.io into our existing pipeline event emitter
- Correctly use Google Analytics' reserved event properties (**Categories**, **Actions**, and **Labels**) for better reporting from within the GA interface

**N.B.** Some of the new events added by this PR require Segment.io's Python module. I've renamed Miles Steele's `analytics` module to `instructor_analytics` to avoid a naming conflict with Segment.io's module, which has been added as a new dependency (@feanil, FYI). Segment.io's module uses a single extra thread to batch messages and flush them asynchronously to Segment.io's servers. Flushes occur the first time a message is received and every 50 messages thereafter, or if 10 seconds have passed since the last flush. The message batch size is configurable - I've changed it from the default 20 to 50, but am interested in what others think the best size is.

@dianakhuang and @mulby, could you help me review this? @shnayder and @griffresch, FYI.
IIRC we were calling unenroll_done first because it was actual business logic that updated state, while emit_event was purely informational (and significantly less important). If someone introduced an error in emit_event, it would never prevent the state from being updated correctly. I would recommend moving it back.