Simplify configuration

Using the Spring ApplicationContext directly was a good idea for rapidly developing the library, but end-users should expect that configuration is much simpler.

At the very least, configuration from the user's perspective should not include a lot of the Spring specific mumbo-jumbo (i.e. "beans", "className", etc.).

Streamline the invokation process

It seems to me that a user ought to be able to invoke the CsvObjectMapper, going in either direction, from one class. Additionally, mappings ought to be on a per class basis so that the name of the mapping need not be passed into the mapper at any point.

Re-evaluate the use of commons-jexl to resolve mapping expressions

commons-jexl is very neat and inexpensive, but there might be more appropriate solutions to the problem out there (ex. domain specific language and groovy?).

De-couple CsvObjectMapper from csv4j

I love csv4j, but I have been cursed by its adherence to the CSV RFC on more than one occasion. Therefore, I would like to introduce an adapter framework into the CsvObjectMapper whereby csv4j will be the default CSV parser, but a user may plug in any of the supported CSV parsers.