Streamline inter-target build dependency management

[nirbheek]

Currently, a build target can depend on other targets in the following ways:

1. dependencies: and link_*: to depend on built libraries and shared modules
2. Adding to the sources, which does some magic:
   • Adds an order-only dependency on generated files with unknown extensions
   • Builds all sources with known extensions and links it into the output

(2) has the following problems:

• Hard to discover, and makes build files difficult to read (why is this custom target added to the sources when it's not a source file?)
• No way to add an order-only dependency on a generated source file: f.e.x, if you have an executable that reads a generated .c file at runtime and you do not want it linked into the target.
• No way to add an order-only dependency on a build target used at runtime: f.ex. if you do an execve() on a helper executable from inside your library or executable.

Solution: add a depends: kwarg that behaves the same way that the depends: kwarg on custom_target() behaves.

We should also deprecate the add-to-sources magic and start printing warnings about unknown sources.

[nirbheek]

We added the depends: kwarg to test() for similar reasons.

[eli-schwartz]

If the purpose of a depends kwarg is for handling runtime use, we do NOT want the same semantics as the depends: kwarg from custom_target, because that triggers rebuilding the target, whereas this proposal is only to cover order-only dependencies that ensures it is "also-built".

It sounds like the real objective here is an alias_target('make-my_exe-work', my_exe, my_generated_file) which can be run before entering meson devenv to guarantee that my_exe does sane things when run from a devenv?

If we assume the "for example"s aren't representative of the issue, but just look at "hard to understand what adding random text files as sources does", then perhaps there is still a reason to do this. idk.