Update docs for job.dependencies and provides/requires

Specify dependent jobs are made available with artifacts.

Specify job.provides/requires is ignored for non-change items.
This documenting implementation made in [1].

Specify examples of passing artifacts for parent/child jobs in
while using job.provides/requires.

[1] https://review.opendev.org/c/zuul/zuul/+/915188

Change-Id: Ibb36ce2fdfa8b07ae399ae69ebf63de663c71fb3

doc/source/config/job.rst

@@ -299,6 +299,17 @@ Here is an example of two job definitions:
       returned by the `provides` jobs will be made available to the
       `requires` job.
 
+      If the child change is enqueued after the moment the `provides`
+      job has finished artifacts are still made available to the
+      `requires` job.
+
+      If `provides` job has failed, then `requires` job is marked
+      as failed and is not run.
+
+      `provides`/`requires` artifact resolution is ignored for non-change
+      items, e.g. for branch items in `supercedent` pipeline, branch items
+      in periodic `independent` pipeline, tag items in `independent` pipeline.
+
       When inheriting jobs or applying variants, the list of
       `requires` is extended (`requires` specified in a job definition
       are added to any supplied by their parents).
@@ -906,6 +917,11 @@ Here is an example of two job definitions:
       completed successfully or have been paused, and if one or more of
       them fail, this job will not be run.
 
+      The dependent job is provided with :ref:`artifacts <return_artifacts>`
+      returned by preceding jobs, e.g. if jobC depends on jobB, jobB
+      depends on jobA, then jobC is provided with artifacts from both jobA
+      and jobB.
+
       The format for this attribute is either a list of strings or
       dictionaries.  Strings are interpreted as job names,
       dictionaries, if used, may have the following attributes: