Those are methods that are probably useful to some applications, and it
feels like some of that data should even be in the file header. Due to
the evtc limitations though, we need to loop through the events to
access it, which means that every application would have to implement
this.

Those functions should be kept in a separate impl though, as they are
more costly to call than the other accessors. Maybe they should even be
moved to an "extension trait", though it's not clear whether putting
this behind a trait would be idiomatic Rust. The advantage would be that
users would have to specifically import the trait, thereby making sure
they're aware of the performance implications.

This file was a big mess of different local experiments of playing
around with the API. It didn't get updated with the rest of evtclib and
consisted of 80% commented lines that once tested something and are now
useless.

We can have a nice small main.rs in the future that can be used to print
out some basic information about a given log file, or rely on examples
to demonstrate the API capabilities. But this abomination that was
main.rs should be gone.

Hooking into the standard Rust system is probably better in the long-run
than having those separate from_raw methods on all of our objects.

Most end users probably won't even need them, as they will use the
higher level functionality provided by evtclib::process.

The module contains some useful structs which were otherwise not exposed
in the public API, so it's better to make it public. The re-export of
Event and EventKind can stay, for convenience.