Spade processor event protocol

This change lays the foundation to add more than one line parser to our processor tier.

The primary changes are:

 - Provide the `parser.Parseable` interface, which decouples the `parser.Parser` interface from the underlying line format. The main aim here was to control the struct being imported in a lot of places, which made initial refactoring hard. I think it is probably possible to not have needed this.
 - Providing a registry in the parser package which parser implementations can register themselves with, this will permit us the ability to test lines against specific parsers and return the least erronous one.
 - migrate the nginx parser into package parser/nginx, this makes space for the json line parser which will land soon

There are a small handful of cosmetic changes, these were in commits  ad95bb0 and  e6b21da.

The follow up work is:

 - create the json based line parser (which will use the new [event protocol in scoop_protocol](https://github.com/TwitchScience/scoop_protocol/blob/spade_edge_event_protocol/spade/event.go))
 - the payload in the json and nginx formats are essentially the same, so the unescaping / decoding that the nginx parser does will be moved to another package
 - establishing logic around how `fanoutParser{}.Parse()` dispatches and records success, this may result in us paying attn to error values from various stages; currently we ignore them in preference for overloading `parser.MixpanelEvent{}` with error information.
So your concern is that you want the most likely case to be run first? I can get down with that. Perhaps something is inferred from the file name and that meta data is passed along?

i.e. file_foo.log is processed by the log_parser and file_foo.json is processed by the json_parser ?