Do not add implied branch matchers in project-templates

We parse the project-pipeline definition of a job at the location
of the project-pipeline.  This includes both 'project' stanzas and
'project-templates' which are parsed in exactly the same way.  This
normally gives us the behavior we expect in that the job variants
defined by the project or project-template appear to be defined in
the location of the project or project-template.  However, in one
case, we want a 'late-binding' rather than 'early-binding' behavior.

When it comes to calculating implied branch matchers, we want to
use the value that would be derived if there were no project-template,
and instead the job were simply defined on the project stanza itself.

What is intended to happen is that project-pipeline job variants in
a config project should never have implied branch matchers (since
config projects don't have more than one branch).  However, project-
pipeline job variants on in-repo project stazas should get an implied
branch matcher for the branch it's defined on.  This is how we end up
with behavior where the project definition in a project's master branch
controls behavior only on the master branch (unless branches are
explicitly specified), and the definition in a stable branch controls
only the stable branch.

That behavior should happen regardless of where a project-template is
defined.  Currently we are setting an implied branch matcher for job
variants in a project template at the location of definition.  Instead,
set them when the job is actually used in a project.

Change-Id: I5c8fbb3e0a2ecfac8bd95795be002e8cd15e61db

doc/source/user/config.rst

@@ -653,10 +653,22 @@ Here is an example of two job definitions:
         configuration, Zuul reads the ``master`` branch of a given
         project first, then other branches in alphabetical order.
 
+      * In the case of a job variant defined within a :ref:`project`,
+        if the project definition is in a :term:`config-project`, no
+        implied branch specifier is used.  If it appears in an
+        :term:`untrusted-project`, with no branch specifier, the
+        branch containing the project definition is used as an implied
+        branch specifier.
+
+      * In the case of a job variant defined within a
+        :ref:`project-template`, if no branch specifier appears, the
+        implied branch specifier for the :ref:`project` definition which
+        uses the project-template will be used.
+
       * Any further job variants other than the reference definition
         in an untrusted-project will, if they do not have a branch
-        specifier, will have an implied branch specifier for the
-        current branch applied.
+        specifier, have an implied branch specifier for the current
+        branch applied.
 
       This allows for the very simple and expected workflow where if a
       project defines a job on the ``master`` branch with no branch