Allow specifying output field when using `unknown=INCLUDE`

[sloria]

From #524 (comment)

We could even go further and let the user set a default Field when using INCLUDE, but I'm not sure it is so useful, and it is never too late to add it in a later step.

(edited to make the argument name correct)

I suggested here that a field could be passed to unknown, e.g. unknown=fields.Str().

[podhmo]

from #718

If the hook that unknown field is found is existed, then, enable to support jsonschema's additionalProperties feature. Moreover, supporting patternProperties, somehow knowing the information about field's name is needed.

So, personally, I want to the hook point of handling unknown fields with field name (It is OK, even if cookbook-level-code(supporting it with your custom implementation), if possible).

[LukeMarlin]

Hi. I'd be interested in making this possible. My use case is the same as described by @podhmo: we generate code out of openapi specs, and to support "additional_properties" this would be ideal to have the possibility to give a field.Field to unknown.
I've been looking at Schema._deserialize so far, and I've noticed two possibilities: reusing the code that deserializes declared fields in the unknown == INCLUDE case, or change load_fields so that unknown typed fields would be considered "first class citizens" and follow the normal procedure.

If you guys are still interested in making that possible, I could give it a try. I'm not familiar with the internals though, so I'll gladly take any hindsight and pointers that could help me

[Br1an67]

I'd like to work on this. Allow a Field instance to be passed to unknown, so unknown values are deserialized through that field (with validation and type coercion).

PR: #2911