Add Support for More Flexible ObjectMapper Configuration

[apjoseph]

Adds the following

• Support for configuration of separate binding and mapping ObjectMappers
• Support for using named ObjectMappers stored in the Rosetta Singleton
• Annotations to support the above at the SqlObject level (example of usage here )
• Convenience methods added to RosettaJDBIBinder for usage with SQLStatement<?>s (example usage here)
• A test using an in memory H2 database connection to catch potentia ObjectMapper resolution bugs

[jhaber]

Hey Andrew, thanks for the PR! To make sure I understand, what was the thinking behind having separate objectmapper for mapping and binding? I just want to make sure we strike the right balance of configurability vs. complexity

[apjoseph]

Since serialization happens both during binding and mapping, distinct serializers for the same type may be necessary for mapping and binding. An example of such a case would be INSERT...RETURNING a JTS Geometry into a Postgis database, where it is sometimes necessary to write a string that looks like SRID=4326;POINT(-97.8173642870078 30.4585857377395) and read a string that looks like 0101000020E61000007B674CB24F7458C0D400FADF65753E40 due to some type casting issues in Postgres. In the current Rosetta revision, it is possible to accomplish this by switching out the ObjectMapper manually between read and write operations. However, if reading and writing are done in the same statement, this is impossible. The only real change needed to make all of this work was adding an additional attribute to theStatementContext and a few helper methods -so I figured the change was well worth it.

For the basic use case, one ObjectMapper is used for both mapping and binding, as was the case previously -thus, the new functionality covers a wide array of edge cases that could potentially reduce some users to tears and cause premature hair loss -while simultaneously being basically invisible and non-intrusive to users who could not even conceive of the need for such functionality.

Ideally, Jackson ObjectMappers would have a mechanism for registering context dependent serializers/deserializers so that one mapper could be used in all instances -but sadly Jackson has no such functionality. It is not even possible to deserialize using custom mixins without cloning the ObjectMapper; as a result, each distinct set of mixins requires a new object mapper. Even if Jackson did support context dependent configuration, it would certainly not be backwards compatible with older versions of 2.x.