Speedup caching of audbcards.Dataset

[hagenw]

When caching audbcards.Dataset we store objects that are not needed to create a datacard,
e.g. the dependency table and header of a dataset. This increases the size of the cache and makes loading slower than it is needed.
This pull request speeds up caching of audbcards.Dataset by pickling only cached properties, as listed by audbcards.Dataset._cached_properties() (formerly audbcards.Dataset.properties()).

The execution time for building our database overview page is as follows on compute5:

branch	fresh build	build from cache
main	15 minutes	3 minutes
this branch	15 minutes	2 minutes

The size of the cache is reduced from 2.6G to 133M.

We can further improve execution time by also caching the images / audio examples from audbcards.Datacard, but I will handle this in a follow up pull request.

---

Further changes:

• Renamed audbcards.Dataset.properties() to audbcards.Dataset._cached_properties()
• Added cached property audbcards.Dataset.schemes_summary, that holds entries needed for the dataset overview page
• Added docstring for audbcards.Dataset.cache_root attribute
• Converted audbcards.Dataset.deps and audbcards.Dataset.header to properties, and added them to the documentation
• Added audbcards.Dataset.backend and audbcards.Dataset.repository_object properties
• Removed adding __getstate__ and __setstate__ methods to the dohq_artifactory.GenericRepository object, as the repository is no longer pickled

---

Newly added API entries:

[ChristianGeng]

This achieves a smaller footprint by changing the caching mechanisms,
and now distinguishing between cached properties and "normal" ones, i.e. between ones decorated with @functools.cached_property and others decorated with @poperty.

These are treated differently now, with the heavy ones that are conceptually not descriptive of a adtaset - backend, deps, header, repository_object - as "normal ones" that are not being cached.

These "normal" properties also have a kind of lazy loading implemented, and are loaded once in the lifetime of an object. As data-artifacts are slowly changing (and audbcards descriptives too), I can see no problem with that - so one does not have to deal with datasets that change during the liketoime of an object. So I belive this is fine.

The whole MR makes the process of building the "carddeck" 50% faster, but the saving in disk space is by a magnitude larget which is great.

The tests cover the new features and look sound to me.

The only concern I have is about dependencies: is the code depending on a newer version of audbackend already? I see not changes in the pyproject.toml.

I do not think this will be a great deal and am approving tentatively.

[hagenw]

The only concern I have is about dependencies: is the code depending on a newer version of audbackend already? I see not changes in the pyproject.toml.

No, this does not yet depend on a newer audbackend version (version 2.0.0 is also not released yet, but consists only in the dev branch of audbackend). I will prepare a pull request for testing audbackend 2.0.0 after the caching speed is handled to avoid merge conflicts.