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.
I'm a little on the fence about the event names.

We usually engage in a rather extensive debate about how they should be named and I don't want to hold up this PR with that effort. However, having them named so similarly to our convention implies that work has been done.

Would you rather go down that rabbit hole? or defer that work until later and leave the existing names as they were?