Expanding on the default unpickling behavior of objects that do not implement __setstate__

Beginne mit dem Dokumentationsabschnitt, der getstate, setstate und das Verhalten beim Unpickling erklärt. Stelle klar, dass Tupelzustände akzeptiert werden, unterscheide direkte dict-Aktualisierungen für dynamischen Zustand von setattr-Aufrufen für Zustand mit Slots, und erläutere das relevante Verhalten, ohne dich auf den bestehenden vagen Hinweis zu stützen.

Documentation

I'm about to open a PR for it myself but I wanted to also open a related issue (just in case there are any objections)
Ever since Python 3.11, __getstate__'s default implementation has been added to object. With that change, the section explaining __getstate__ was expanded to also explain the default implementation in regards to slotted objects and the fact that their default state is a tuple of dicts (1 for the slotted dict and 1 optional dynamic dict) .

With this change, the user is now aware of the new concept of the "slotted state" and therefore should be aware of how it is handled when __setstate__ was not implemented. The current documentation states that the user may choose to implement __getstate__ and not __setstate__ so long as the returned state was a dict.

This needs to be updated to explain it also accepts tuples of the former format. Moreover, it should be updated to explain how do these 2 dicts differ in their setting behavior:

1. The dynamic dict MUST be set using direct edit of the instance's __dict__ (in order to not activate __setattr__ which is very important, especially on immutable instances that will throw an exception on such calls). This is behavior is similar to pure dict states (and should probably be documented as well)
2. The slotted dict MUST be set using calls to setattr (since they by definition do not exist on the instance __dict__ and therefore cannot be directly edited. Also we want to avoid accidentally a duplicate value on that dict)

Explaining this behavior will be more detailed and helpful than the current note that vaguely states:

At unpickling time, some methods like __getattr__(), __getattribute__(), or __setattr__() may be called upon the instance. 
In case those methods rely on some internal invariant being true, the type should implement __new__() to establish such an invariant, 
as __init__() is not called when unpickling an instance.

Explaining it will also prevent users from mistakenly relying on __setattr__ when they shouldn't. This will also prevents libraries like jsonpickle from incorrectly implementing their unpickling behavior to always use setattr (which causes bugs that arise from discrepancies with the default pickle library.