Potentially backward compatibility breaking change

In the original version of GitSCM.buildEnvVar, the code reads as follows:

-------
        Revision rev = fixNull(getBuildData(build, false)).getLastBuiltRevision();
        String singleBranch = getSingleBranch(build);
        if (singleBranch != null){
            env.put(GIT_BRANCH, singleBranch);
        } else if (rev != null) {
            Branch branch = rev.getBranches().iterator().next();
            env.put(GIT_BRANCH, branch.getName());
        }
-------

As you can see, the code takes a different path if getSingleBranch(build) returns non-null, and when it does, the branch name does not contain the repository name, such as just "master". OTOH, Branch.getName() always returns a branch name prefixed by the repository name, such as "origin/master".

I noticed this behaviour difference when I was working on a test regression in this, and upon understanding what's going on, I think the original code creates a behaviour inconsistency --- either we should always return "origin/master" or "master", regardless of whether the kind of checkout happens to be a single branch build. In this change, I'm opting with "origin/master", given that when multiple repositories are involved, "master" alone won't be unique.
Extracted ignoreNotifyCommit to a fake extension point
wrong UI control
Split off ScmName as a fake extension
split off LocalBranch into its own extension point
test case for basic configuration roundtrip
for config roundtrip consistency, fix up empty strings
fix up for the local branch split
databinding requires this name to be consistent
Yay! Got rid of the advanced configuration section.

Every fringe use case is now implemented as GitSCMExtension
a bit of simplification
follow up bug fixes