Previously, all job definitions where shared across each .zuul.yaml in
both branches. When a job definition was changed in one branch, Zuul CI
could pick the job definition from the other branch, which was not
intended.

The problem arises when mixing explicit job.branches matchers with
implicit branch matching, when defining same jobs on multiple branches.
Zuul CI expects that jobs to be defined in one or the other branch, not
both at the same time. One should only use job.branches matchers from
single-branched projects, e.g. trusted config repos. When defining jobs
in branched repositories one selects which job definition to use by the
branch associated with the triggering event instead.
Each trigger has a branch associated with it, whether it is the branch
targeted by the change being proposed, the branch to which a commit
merged, a branch attached to a timer trigger etc. This branch name is
searched across involved projects in order to determine what job
definition should be used.

The job.branches directive is rarely applied to a job which will be
copied to multiple branches. When you have multiple copies of a job
with the job.branches attribute, Zuul CI could pick any of the job
definitions which might not be the one you expected.
The job.branches attribute is useful in single branch config
repositories where a specific job definition has to be applied to a
specific branch of the repository. Another definition of the job
will exist in another branch of the config repository.

This patch removes job definitions which are specific to other
branches, except for parent jobs which are shared across branches.

Signed-off-by: Jakob Meng <code@jakobmeng.de>
Change-Id: Idb8720bd96843b7807dd5cb62b30c1edf3a7a37c