Add analytics tracking for core actions

[joshsmith]

Problem

Here are the remaining core actions we need to track:

• [ ] Reordered Task in List
• [ ] Connected GitHub App Installation to Project

Some we can't do yet but should be able to soon:

• [ ] Sent Suggested Tasks Email
• [ ] Opened Suggested Tasks Email (using email provider's API?)
• [ ] Clicked Suggested Task in Email (using email provider's API?)
• [ ] Signed Up with GitHub

[joshsmith]

From @begedin in #1105:

I've spent time trying to implement tracking for the case of a position change. However, due to our use of EctoOrder, I was unable to find a way to reliably determine if the change took place.

• :position field is virtual and is nil upon initially loading the Task
• :order field is set internally by EctoOrdered. A "rebalancing" step takes place during insert or update, which effectively can change its value even if no actual change took place
• tracking params received from the client also isn't an option, since they could contain a value for position which doesn't actually make a change to it

For now, best I could do is add the order field to the task traits in tracking and work with "Edited Task". If you have a better idea, I'm happy to implement it.

On the note of GithubAppInstallation tracking

• this PR tracks CodeCorpsWeb controller actions only, meaning

  • when user creates an installation from the client app (not actually on github yet, necessarily)
    • this installation is immediately connected to a project, so I don't think separate tracking of that makes sense in the context
  • when user clicks connect on the repo, creating a ProjectGithubRepo

• what else do we need to track

  • when an installation is created from github - it will either just be saved, unconnected to a project, or it will be matched to an existing installation created above and then connected to a project - 2 events
  • when an installation is removed from github

The problem with this new tracking, however, is that there's no current_user within that context, so we either need to track without it, or figure out a way to provide it. In most cases, for example, we could use the sender object within the github payload to try and match to a CodeCorps user. However, there are still cases where this does not exist, so in that case we either provide a bot user as context, or we provide no context at all.

[zacck-zz]

@joshsmith @begedin I would like to try out implementing the remaining tracking?