Remove ability to `__setstate__` from "legacy" tuple format soon

This original issue #1004 describes the problem with returning a tuple from __setstate__, so #1009 removed it. But once new release was actually cut #1085 reported that this actually broke a lot of stuff, and support for unpickling from tuple was added back in.

The problem with this is that anyone who stores pickled representations of their objects with code using versions prior to 22.2 is till vulnerable to the issue described in #1004 ( potentially assigning a wrong value to a an attribute on unpickle).

Let's try to really remove the support for tuple on deserialisation in a newer version (best is 22.3) once more people have had a chance to re-process their data using newer code.

I don't think we can ever guarantee that no one in the world will be hit by the issue like #1085 again, but at leas at this point there will be an officially released version (the first one containing #1085) that can be used to re-process the data once the support is gone from trunk.

Storing data in long term storage remains a bad idea that maybe Python official docs could do more to warn people about alongside the security concerns (which are very prominent in the docs).

Read issues #1004, #1009, and #1085 first to understand the tuple deserialization compatibility history, then locate the relevant handling in attrs. The work is done when legacy tuple support is removed without reintroducing the breakage described in #1085, with the affected compatibility behavior covered appropriately.