Split classes, add explicit error handling

[MichaelXavier]

This is for #24

@ozataman @bitemyapp please weigh in. Relevant explanation from the commit log:

I decided to scrap the idea at least in this first attempt of preserving the CSV class. It is really easy to upgrade and we would definitely put this behind a breaking change. Once I got into the code I realized keeping the CSV class would mean either:

1. Making it a superclass of both From/ToCSV and have it be completely empty, which seems silly. Explicit instances people wrote for CSV (admittedly rare, I'd think they'd piggyback on the existing ones) would still break.
2. Using ConstraintKinds we could do type CSV s r = (FromCSV s r, IntoCSV s r) but this would put a hard limit on supported GHC versions (something I don't necessarily object to but it seems like a trifling reason here) and would probably be kind of confusing to those unfamiliar with that language feature. Plus I think the language pragma would be viral, meaning they'd have to add it to files that had CSV in the type signature if I'm not mistaken.

Thanks to the split, it allowed me to add a NamedE variant of Named that does not erase parse errors and provide only the parsing instance without having to provide a nonsensical serialization instance.