Store dependency table as parquet on backend

[hagenw]

Closes #397

In #372 we switched the format of the dependency table from CSV to PARQUET, which uses already the fast SNAPPY compression algorithm to reduce it's size slightly. We still did compress the file further before uploading it as ZIP to the server. The advantage was that the file was smaller, and that we can download the same ZIP file from the server, independent if the dependency table is stored as PARQUET or CSV.

In #397 we show that file reading and writing is much faster when not zipping the PARQUET file for storage on the backend.
Hence, this pull request removes zipping and puts the PARQUET file directly on the server.
To have a single source of truth implementation it introduces the download_dependencies() and upload_dependencies() functions (not part of the public API), that are then internally used inside audb.dependencies(), audb.publish(), and audb.remove_media().

[ChristianGeng]

Description

This stores dependencies for newly loaded deps into parquet format.
This should work as deps.load() and deps.save() infer what to read or write based on the extenstion, so this will not raise compatibility issues.

In addition, the MR also refactors an ugly loop in audb.core.api in favor of two functions in the dependency module, download_dependencies and upload_dependencies. This is nicer to read and in particular download_dependencies contains the management of
define.LEGACY_DEPENDENCIES_FILE, i.e. implements the backward compat with csvs / pickles used hitherto.

I understand that unit testing these new functions will be quite hard, and so it is fair to handle testing in an integration testing approach when calling api.dependencies.

So without further ado, I would say that this can be approved.