New library metasystem

Hi!
In the process of porting an application to Meson I met two design issues of pkg-config, described [here](https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/54) and [here](https://bugs.freedesktop.org/show_bug.cgi?id=105572). Firstly, pkg-config does not know what type of a library it deals with so it can't return correct flags for linking without adjusting of either metafiles or CLI parameters. Secondly, pkg-config in some situations requires presence of metafiles which in theory it does not need.

As aforementioned issues can't be fixed without breaking compatibility, I suggest to design a new library metasystem. My thoughts on new design are following.

## A metafile description
A metafile with some name and extension '.lm' corresponds to a library with the same name. This allows to determine more easily the type of a library (shared, static, both) by checking existence of corresponding files. A metafile has the following format:
```ini
# This file contains metadata describing the library 'foo'
# All fields are optional (empty file is a valid file)

[Library]
Version=1.0.0
Description=A library for ...
URL=https://example.com/

[Paths]
PathLibrary=/full/path/to/the/library
PathHeaders=/full/path/to/the/headers1
PathHeaders=/full/path/to/the/headers2

[Dependencies]
RequiredHeaders=bar1/bar2/bar3 # refers to the .lm files
RequiredLibraries=bar1/bar2 # refers to the .lm files or libraries in standard location
Versions=bar1 >= 1.0.0/bar2 >= 2.0.0

[C/C++]
Definition=definition1
Definition=definition2=1024
CompilationArgument=-pthread
LinkingArgument=-pthread

[Variables]
UserVar1=true
UserVar2=1
```
The format imply different dependency chains for compiling and linking. This allows to express critical, visible and invisible dependencies ([link](https://bugs.freedesktop.org/show_bug.cgi?id=105572#c1)) without overlinking or excess CFLAGS or headers.

## How it is supposed to work
1. Meson retrieves standard search directories for libraries from a compiler (`g++ -print-search-dirs`).
2. A user declares a dependency for a project: `some_dep = dependency('foo', type: 'compile-time'|'link-time'|'both')`.
3. For the `type: 'compile-time'` Meson searches for a file 'foo.lm' in a path provided in a parameter or an environment variable. If the metafile is found Meson calculates compiling flags by combining Paths.PathHeaders, C/C++.Definition and C/C++.CompilationArgument from each metafile in the dependency chain. If any metafile can't be found Meson raises an error (metafiles is the only way to locate headers).
4. For the `type: 'link-time'` Meson searches for a file 'foo.lm' in a path provided in a parameter or an environment variable. If the metafile is found Meson calculates linking flags by combining Paths.PathLibrary, the name of the library (it is equal to the name of the metafile) and C/C++.LinkingArgument from each metafile in the dependency chain. Dependency chain is calculated taking into account the type of a library some metafile belongs to. If any metafile can't be found Meson assumes that provided name directly refers to the library in the standard location (and checks it at configure time, and gives a warning if this is a static library).
5. For the `type: 'both'` (default) Meson does both points 3 and 4.

Comments are welcome.

My questions are:
1. Is a Meson team interested in a new library metasystem?
2. Seems with explicit declaration of types of dependencies Meson can generate suggested metafiles automatically in most cases (if you don't use preprocessor definitions in headers). Am I wrong?