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.

[bitemyapp]

ConstraintKinds we could do type CSV s r = (FromCSV s r, IntoCSV s r)

I think the most salient reason not to bother with this is that it doesn't have to live in the library. Anybody that wants to defer migration or migrate incrementally from the unified class to the split class can add the constraint alias themselves. I don't have an objection to the extension itself because I use ConstraintKinds prolifically for database stuff.

[dmvianna]

This looks very old, and the participants seem to have not converged on a decision. I'm going to close it, but feel free to reopen.