Fix inheritance resolution of cached properties in slotted class

[dlax]

Summary

This resolves the case where a sub-class of a slotted class defining some cached properties has a custom __getattr__() method, illustrated in #1288 (but not exactly the same example, rather #1288 (comment)). In that case, we need to build the custom __getattr__ implementation (see in _make_cached_property_getattr()) using cached properties from all classes in the MRO. In order to keep references of cached properties defined the inheritance hierarchy, we store them in a new __attrs_cached_properties__ attribute and finally build the cached_properties value, passed to _make_cached_property_getattr(), by combining current class' cached properties with that of all its parents. Also, when building __attrs_cached_properties__, we now clear current class' __dict__ (name cd), thus saving an extra loop.

Pull Request Check List

• Do not open pull requests from your main branch – use a separate branch!
  • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
  • This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
• Added tests for changed code.
  Our CI fails if coverage is not 100%.
• New features have been added to our Hypothesis testing strategy.
• Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
  • ...and used in the stub test file tests/typing_example.py.
  • If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
• Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changes to the signature of @attr.s() have to be added by hand too.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    The next version is the second number in the current release + 1.
    The first number represents the current year.
    So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
    If the next version is the first in the new year, it'll be 23.1.0.
• Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) have news fragments in changelog.d.
• Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

[dlax]

Closing in favour of #1291