Add field-level pre/post-load API

[sloria]

As suggested by @lafrech in #2786 (review), we can enable pre/post-load on fields to address use cases like whitespace trimming (#1391) via an API similar to the schema-level pre/post_load/dump API.

Something like:

from marshmallow import Schema, fields

class ArtistSchema(Schema):
    name = fields.Str(post_load=(str.strip, str.upper))
    email = fields.Str(post_load=(str.strip, str.upper))

# and/or

from marshmallow import Schema, fields, field_post_load

class ArtistSchema(Schema):
    name = fields.Str()
    email = fields.Str()

    @field_post_load("name", "email")
    def strip_whitespace(self, field_name: str, value: str) -> str:
        return value.strip()

• pro: allows field-specific transformations without having to implement a custom field
• pro: non-breaking change
• con: overlaps with existing functionality provided by custom fields and the schema-level @pre/post_load

Alternatives considered

Allow validators to transform values

• same as pydantic and sqlalchemy
• pro: minimal API surface added
• pro: minimal internal code changes
• con: it's not intuitive that validators can mutate values
• con: doesn't solve for pre-validation transformations or dumping/serialization
• con: breaking change

[llucax]

Why is this considered a breaking change?

[sloria]

sorry for the confusion. The breaking change refers to the 'validators transform values' alternative, not the proposed approach

[sloria]

on second thought, i don't think field-level pre/post-dump makes as much sense as pre/post-load. field-level transformations are much less common on serialization than in deserialization, and custom fields already address the rare cases when they're necessary.

[sloria]

I also have medium confidence that @field_pre/post_load is unnecessary. the schema-level @pre/post_load already provides functionality for doing transformations on one or more fields.

[sloria]

proof of concept of the pre_load and post_load parameters in #2799