Add extension point for overriding POJOPropertyBuilder functionality (Scala, Kotlin)

[cowtowncoder]

One of biggest challenges supporting handling of value types of non-Java JVM languages like Kotlin and Scala is the fact that they have more advanced facilities for defining value types (like case / data classes), and using naming conventions that often differ in some ways from Java Bean convention (esp. since Java Beans only rely on getter/setter whereas newer approaches start with fields).
Work so far (up to 2.10) has tried to tweak existing one-size-fits-all behavior; and even some newer ideas focus on adding on/off features to support some of edge cases (like Kotlin's "is-getter" naming discrepancy from Java Beans).

But maybe it is time to think of bigger picture: what if it was possibly to do something similar to Bean[De]SerializerModifier -- which allows changing set of properties a (de)serializers has, their ordering (for serialization), or even replace standard (de)serializer completely -- but at an earlier point, where individual "accessors" (prospective getters, setters, fields) are being connected.
At this point it should be possible fully override rules of how accessors are combined (f.ex allow case-insensitive matching, or to start with specific accessor (fields) instead of trying to mangle names in isolation), and perhaps even change name mangling basics (apply different rules of determining likely "implicit name" before explicit renaming by annotations).

I am not sure exactly how this should be done, but this functionality should probably change behavior of at least:

• POJPropertiesCollector: container for information on all logical properties of a POJO, tentative properties: contains a set of POJOPropertyBuilders
• POJOPropertyBuidler: container for information on a single individual tentative POJO property

After application of extension point(s) behavior should be unified in that core jackson-databind would simply use modified set of properties to create otherwise regular Bean[De]Serializers, without further need for further custom implementations (or at least much reduced need for complete replacements).

[cowtowncoder]

Decided to go in bit different way, updated original #2527 to describe this third approach that I will actually use, close this one.