Provide abstraction over the affordance payload metadata that considers (de)serialization customizations

From the discussion in #1573.

I've considered this change and decided not to pursue that route. Jackson's (de)serialization customizations are applied to runtime instances of ObjectMapper. How those instances are configured and how that configuration affects the (de)serialization is guarded by the OM's implementation details. That's why I don't think we should continue to bake more (de)serialization related aspects into the statically computed property metadata that is primarily driven by the logical view on the type to be serialized, the constraints imposed on the properties etc.

I am not certain that we can still do this in the 1.4 timeframe, but I would rather like to move to an abstraction that exposes (de)serialization related metadata based on the OM instance in use to the media-type-specific infrastructure, so that e.g. the code rendering HAL FORMS can access that metadata as bean, which in turn consolidates the property metadata with the Jackson (de)serialization settings.

There's precedent for this approach in Spring Data REST's MappedProperties, which (unfortunately) uses Spring Data's PersistentEntity abstraction as foundation, but we should be able to come up with something similar.

Start with the discussion in #1573 and inspect the existing statically computed property metadata and media-type-specific infrastructure. Compare the proposed abstraction with Spring Data REST's MappedProperties and determine how it should use the active ObjectMapper configuration. Done means the design and integration path are established for exposing consolidated serialization metadata to HAL FORMS and similar consumers.