Feature: add blueprint for msgspec

[Jyckle]

Hi all! I regularly use the wonderful library msgspec within Django projects at times when I don't want a full Django serializer. I also have the good fortune to use this wonderful library that you all maintain! I recently got the two to work together cleanly, and wanted to put it out here for others!

I'm very curious what all would go into allowing further support (integrating msgspec support to the library like you all did for pydantic), but I figured this was a good place to start, and then I could ask questions as needed if that further integration was something you all would even have interest in!

A very simple example of how this could be used:

import msgspec
from rest_framework.views import APIView

class A(msgspec.Struct):
    identifier: int
    
class MsgspecView(APIView):

    @extend_schema(
        request=A,
        responses={200: list[A]},
    )
    def post(self, request, *args, **kwargs):
          pass

[CharString]

Cool. Have a look at https://github.com/maykinmedia/open-beheer/blob/main/backend/src/openbeheer/api/drf_spectacular/schema.py. I think it's a lot simpler. I would appreciate your opinion if you think it's too simple.

[Jyckle]

Cool. Have a look at https://github.com/maykinmedia/open-beheer/blob/main/backend/src/openbeheer/api/drf_spectacular/schema.py. I think it's a lot simpler. I would appreciate your opinion if you think it's too simple.

Oooooo I like your implementation a lot! That's much cleaner than my hack at it! I think that is both simpler, and more flexible! I think getting your version added to the blueprints would be great, if you're up for that!

[tfranzel]

@CharString @Jyckle if any of you want to replace the blueprint code in this PR for the "better" implementation, be my guest.

Happy to have this at least in the blueprints.

[Jyckle]

I went ahead and pulled in some of the changes! @CharString I tried to keep it simple for the sake of the blueprint, but I saw that you also had some more recent changes to how you have it set up! If you think any of those changes would be important to include here, just let me know! I think it should be functional as is though

[CharString]

@Jyckle Off the top of my head:

My recent changes were to deal with the fact that annotations can either be the type object itself, or a forward ref.
The resulting schema would be okay, but spectacular would warn that the forward ref and the object are not the same:

Warning [ZaakTypeDetailView > _GenericAlias]: Encountered 2 components with identical names "ZaakType" and different identities <class 'str'> and <class 'openbeheer.types.ztc.ZaakType'>. This will very likely result in an incorrect schema. Try renaming one.

If we add tests for to this PR, adding ones that have from __future__ import annotations should surface these problems.

I went with a simple solution that worked for our use case. But I think a more general solution would use get_annotations. This is new in Python 3.14, but typing_extensions has a backport for older versions.