Breaking out msg/time/level

The first commit (fe381bf) just adds some text_formatter unit tests.

7679f44 changes `Entry` to the structure I discuss in #29 and #30. It removes `msg`, `time`, and `level` from the `Data` map and makes them first-class `Entry` fields. This moves the mapping of level to string entirely into the formatters.

This modifies the default JSON format, causing it to encapsulate additional fields in a `data` sub-object. I believe this is a better JSON format because it doesn't have any magical fields. But it is trivial to implement the previous "flat" JSON in a formatter. Just copy the data map into a new map and merge-in the three magical fields, and marshal that. I'm happy to write a `FlatJSONFormatter` if you think it's useful to anyone.

I also changed the JSON encoding of Warn to "warn" rather than "warning" for consistency. That's trivially reverted in json_formatter.

I've added `Unformat()` methods on the formatters to assist in testing. I haven't added that as part of the `Formatter` interface, however. `Unformat()` may be very inconvenient to write for some formats, and I don't know if it's worth making it mandatory. It's probably worth adding an explicit `Unformatter` interface.

I haven't finished the text unformatter yet; I only handle the colorized case. Testing the other case is a bit of a headache currently because of how it checks for the terminal. It is probably worth reworking ForceColor to an enum (color/plain/auto). The whole auto-detect has a lot of tricky corner cases, anyway. If the log output isn't stdout, then it's not clear what to check. Personally, I'd like color/non-color to be split into separate formatters and let the caller work out what they want.

I'd also recommend that the formatters be moved into sub-packages like the hooks. There's no reason to build all the formatters (and their dependencies, like the JSON encoder) when you're likely to only use one of them. I have a custom formatter package, and don't use any of these. I can make that change if it's acceptable.
I'm not sure what I think about this as a default. Nested hashes aren't the greatest. I get where you're coming from though, since there's no way nice to have this work with keys with the same name.