Make customizing Schema behavior with subclasses easier

This was [mentioned](https://github.com/marshmallow-code/marshmallow/issues/1751#issuecomment-782719165) in #1751:
> I think this is an indication that `Schema` needs to be easier to customize, not that we need to bake more custom functionality into the base schema.

OneOfSchema is just one motivating use-case. More generally, what kind of structures are problematic today for customizing Schema?

---

Some examples of things which could possibly be improved:

1. Customizing `_serialize` and `_deserialize`?

#1726 is all about making `Schema._serialize` and `Schema._deserialize` open to subclasses as a better place to customize behavior. Whether or not `extra={...}` is a good idea (#1726), is making these steps friendly to overload a good approach?

2. Hook execution (order matters)

Often, users want a schema base class which has some fixed "pre_load" or "post_load" behavior. But if a base schema adds a `@pre_load` method, it will get mixed with the potential hooks on subclasses and the user's desired ordering is lost.

One approach would be to let users overload hook processing and rely on `super()` to call the "real" hooks. The signatures for `_invoke_schema_validators`, `_invoke_load_processors`, and `_invoke_dump_processors` are all slightly different. Can they be unified into a method like `Schema.run_hook(...)`? Or, alternatively, replace these with methods like `Schema.run_pre_load_hooks(...)`?

3. Customizing handling of unknown fields

`INCLUDE`, `EXCLUDE`, and `RAISE` are good out-of-the-box behaviors. Looking at issues like #853 , could this potentially be solved by making the handling of unknown fields settable as a hook?

Mainly, the logic is here: https://github.com/marshmallow-code/marshmallow/blob/8af34a94322bf4fff71eaff0f29d5e1655fc9c6e/src/marshmallow/schema.py#L666-L680

What about `Schema.handle_unknown_fields(...)` or some method like that? So the `Schema` class implements today's behavior, and users can subclass and override with their own behaviors.

Start by reading src/marshmallow/schema.py around the unknown-field handling at lines 666–680, then review the customization questions in #1726 and #1751. Compare the existing _serialize, _deserialize, hook-invocation, and unknown-field paths. Done requires a decided, coherent subclass-customization design rather than a single specified edit.

Written by the indexing model from the issue text.