Motivation:

We can declare dependency versions using `dependencies.yml` and share them
across multiple projects. It is useful to manage the versions of various
dependencies. However, we can't define different versions of a module.
Because the unique keys in `dependencies.yml` are `moduleId:artifactId`.

This limitation makes it difficult to manage compatibility between
different versions of a library. For example, okhttp v4 is required to
test `it:okhttp` and okhttp v3 is required to run `retrofit2` module.

Gradle introduced a new way to [share dependency versions between projects](https://docs.gradle.org/current/userguide/platforms.html).
The unique key of version catalogs is a user-defined alias so we can
define multiple versions of a module using different aliases.

Version catalogs do not allow extra properties on `libs.versions.toml`.
It only allows some properties for versions and modules.
`dependencies.yml` not only manages versions but also manages metadata
for a module such as relocations, exclusions and Javadoc links.

I wanted to take advantage of both. We need a version manager that
supports version catalogs based on aliases, and the ability to add the
metadata. As a result, I implemented to add our own dependency mechanism
using `dependencies.toml` that is fully compatible with Gradle's version
catalogs and understands relocations, exclusions and Javadoc links
declarations.

Modifications:

- Migrate `dependencies.yml` to `dependencies.toml`
- Rename `common-dependences.gradle` to `common-dependences-lagacy.gradle` 
  for backward compatibility with `dependencies.yml`
  - Newly added `common-dependences.gradle` handles the dependencies declared by `dependencies.toml`
- Add `version-catalog.gradle` that parses `dependencies.toml` and builds:
  - Library and BOM version catalogs
  - relocations
  - exclusions
  - Javadoc links
- Migrate all dependencies defined in `build.gradle` files to the new version catalog API.

Result:

Fixes #4120