refactor plugin protocol

[Goldziher]

PR Checklist

• Have you followed the guidelines in CONTRIBUTING.rst?
• Have you got 100% test coverage on new code?
• Have you updated the prose documentation?
• Have you updated the reference documentation?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

97.7% Coverage
0.0% Duplication

[peterschutt]

OK, plugins are now generic on both the source data type and the transform type.

I assume this is to allow us to make plugins that transform into msgspec structs?

I know that I'd prefer my DTOs to be msgspec structs and parsed directly from the request buffer, but this will allow users to have a choice.

This plays into a redesign I was already considering for the DTO refactor. At the moment, DTO instances are pydantic models, but they probably need to be their own type, and hold a reference to a thing that does the ser/de and validation, be that a pydantic model, or msgspec struct or whatever, and what that thing is will depend on the type of plugin the dto factory is given.

E.g, if a DTO factory type is given a plugin that is narrowed to pydantic base model, then it will produce a ser/de object that is a pydantic model, if it is given a plugin narrowed to msgspec structs, then it will produce a struct for its ser/de object.

Before this, I was not confident about meeting the 20th deadline (not just for the DTO refactor, but for everything I want to have in 2.0), but I think will be a positive redesign.