Allow customized Schema _serialize and _deserialize to get custom data from load/dump calls

Nobody has claimed this yet.

Although this is contained in #1725, I'm going to try to distill this down to exactly the feature I want, plus the context for why I want it.

-----

This issue originates in an interaction between `marshmallow-oneofschema` ("oneofschema") and `marshmallow-sqlalchemy`. Both of these are important to marshmallow, especially since oneofschema is the go-to answer for questions about polymorphic fields.

oneofschema overloads `load` and `dump` with special operations. This works for most simple use cases, and most features (e.g. `partial`, `many`) are supported.
However, it means that oneofschema doesn't support pre- and post-processing hooks built into marshmallow, and the only way to support them in the current implementation, in which oneofschema replaces `load` and `dump`, is to reimplement the marshmallow load and dump logic.

Looking into options for this, `_serialize` and `_deserialize` are in exactly the right place for oneofschema to overload them with its specialized behavior. As proven in https://github.com/marshmallow-code/marshmallow-oneofschema/pull/130 , the result is smaller code for oneofschema with added support for hooks.

It seems a perfect fit. However...

In https://github.com/marshmallow-code/marshmallow-oneofschema/pull/111 , oneofschema added support for passing through additional keyword arguments from `load` and `dump` to its child schemas. The reason is that `marshmallow-sqlalchemy` also customizes `load` and `dump`, but in a different way. For that library, additional arguments control added behaviors.

If oneofschema starts using `_serialize` and `_deserialize`, it will lose the ability to support the `marshmallow-sqlalchemy` use-case.

If marshmallow wants to support oneofschema in this, I believe it would be best to consider `_serialize` and `_deserialize` part of the public interface for the purpose of subclassing and customizing schemas. The parallel with these method names for Fields already suggests them as semi-public.

The most naive approach would be to allow arbitrary keyword arguments to `load` to go through `_do_load` and down to `_deserialize` (and likewise for `dump`). However, that allows `load` to accept and ignore arbitrary arguments like `parttial=True` -- it makes the experience for users worse.
In #1725 I proposed a specific argument, `extra`, a mapping which exists only to support extensions like oneofschema. I'm open to other approaches. A major version of oneofschema, but not of marshmallow, would be needed to implement the change.

Start by reading the proposed approach in #1725 and trace how load and dump pass arguments through _do_load to _deserialize and their serialization counterparts. Compare the needs of marshmallow-oneofschema and marshmallow-sqlalchemy, then define an explicit extension mechanism that avoids accepting arbitrary misspelled arguments while preserving custom schema behavior.

Written by the indexing model from the issue text.