Add extra data-artifacts to static analysis events

[TimvdLippe]

To improve the data analysis of the static analysis events, the following properties should be tracked as well:

1. The type of event. This should be based on the warning type generated by the editor. Since we are dealing with Strings, we need to create our own classifier to trace back what the original static analysis warning was.
2. The file it was generated in. To make sure we anonymize the data, we should hash the file name. We might even be able to use an id exposed by the editor or its internal hash implementation.
3. The overall time the warning existed. This one requires additional tracking. In other words: if we know of a warning when it was created and in the same session we receive a remove event for that warning, we can compute the overall "existence" time. For warnings that are removed, but generated before this session, we probably have to do a best guess. Same for warnings that are generated in a session but never resolved in that same session.

CC @azaidman and @Inventitech for additional data that we would like to include.

[Inventitech]

For option 2, I recommend taking a look at the existing functionality for Read and Typing intervals. The ids should be interchangeable. For option 3, this sounds to me like the Interval concept would be more appropriate than Event.

[TimvdLippe]

This was fixed in #287