(2.8) Add new method(s) in `DeserializationProblemHandler` to allow handling of format mismatch problems

[cowtowncoder]

(note: based on ideas from #1196)

Existing DeserializationProblemHandler only has one callback method, for handling common case of "unknown property" problem. But there are other types of failures that would probably be possible to route through such handler. One broad class of problems has to do with mismatching values, like getting a JSON String where number is expected, or getting a String with format that is not recognized as valid (such as can occur for Date/Time values).
To allow dealing with such problems, it seems reasonable to add following handlers:

1. Handler for case of mismatched input token type (expected number, got boolean)
2. Handler for case of invalid format (usually String, but not limited)

Note that there may be some corner cases here (f.ex., choice between (1) and (2) may not be clear for secondary/coerced values), but this should cover a few cases.

Compared to the earlier handler there are similarities and differences:

• In both cases, callback is given a JsonParser, and is responsible for using up or skipping any content for structured values (array, object)
• For new methods, return type should be value to use as deserialized value, including possible null -- but since there is no way to indicate "not handled", callback MUST throw exception to halt processing
  • alternatively we could consider possibility of return a Marker object, to indicate "did not process, use standard failure"? While bit hacky, this might be the best way (actually, this could also be one of few cases where I would use Optional...)

To support proper handling, information to pass probably needs to include some of:

1. Contextual object: DeserializationContext, JsonParser, JsonDeserializer in use; bean/class of bean for which value is to be used
2. BeanProperty for which value is meant? (also gives logical name for error reporting)
3. Fail message that would be used for Exception to throw?

Anyway. Details method, arguments to pass etc get complicated and probably need to be refined as part of implementation.

[cowtowncoder]

Note: new methods added in DeserializationProblemHandler now include:

• handleWeirdKey: called when conversion from JSON property name to desired Map key type fails
• handleUnknownTypeId: called when conversion of logical type id fails

and in both cases handler may choose to try to fix the issue, or to throw custom exception. In former case it would be possible to also collect failure notification.

[cowtowncoder]

More handlers added:

• handleWeirdStringValue
• handleWeirdNumberValue
• handleInstantiationProblem

along with tests. No automatic wiring/chaining of exceptions, but handlers can stash problem information as contextual Attributes or such.

Handlers still to add/convert:

• Second part of instantiationProblem (message instead of Throwable)
• "wrong token" problem (and perhaps things that should call this method)
• general reportMappingException/mappingException -- tons of unclassified failures that ideally should map to something meaningful.

[cowtowncoder]

Completed to the degree it will be done for 2.8 I think.