Deprecate projectName setting of CopyArtifact

Starting with version 1.26 of the CopyArtifact plugin all Jenkins job
configurations using this plugin get rewritten on the fly if you run at
least one build. This causes serious failures of the CopyArtifact
feature as soon as the project name includes axis selections.

If the config.xml of a job includes identical project *and* projectName
settings (this is what happens with JJB without this patch), like:

    <project>demojob/axis=$setting</project>
    <projectName>demojob/axis=$setting</projectName>

then it fails to run with current version(s) of the Copy Artifacts
plugin.

The problem is that while the web interface displays the correct
configuration for a fresh job created with JJB (Project Name:
"demojob/axis=$setting" and "Parameter filters" being empty), the
*wrong* configuration is actually used (Project Name: "demojob" and
"Parameter filters: "axis=$setting"). The reason is that when you
execute the job for the first time (after the config.xml was created by
JBB) the Copy Artifacts plugin automatically converts the configuration
to:

    <project>jenkins-debian-glue-binaries</project>
    <parameters>axis=$setting</parameters>

which is something different than wanted and it doesn't work.
This settings stays permanent then until you *manually* fix it.

When you manually select "Configure" on the original job (the one with
project + projectName settings being identical as noted above) in the
web interface without running it first and then click on "Save" it's
fine though, looking like:

    <project>demojob/axis=$setting</project>

Since people usually use current versions of Jenkins plugins (and
version 1.26 of the CopyArtifact plugin was released in March
2013, being ~8 months as of today) and because the python-jenkins
library doesn't offer the ability to query for plugin version
info it's better to just use current defaults instead of breaking
configurations in a quite hard-to-debug way. This also reflects
upstream's opinion about the required change, quoting Jesse Glick
from the Jenkins bug tracker:

| The projectName field is deprecated, and may not be used together
| with project; there is a one-way conversion of projectName (which
| gets deleted) to project plus parameters. If jenkins-job-builder
| writes out a configuration including both fields then it is
| simply buggy.

Change-Id: Ie93316b135dc2b4547922062c7393ea7e5cc4e4c
ModuleRegistry now caches entry points lookup

While profiling JJB with cPython with Wikimedia configuration files, the
top three offenders are:

 ncalls  tottime   cumtime  percall filename:lineno(function)
  60697    3.728    10.753    0.000 pkg_resources.py:471(iter_entry_points)
4903683    3.229     3.810    0.000 pkg_resources.py:2396(get_entry_map)
4936493    3.215     3.215    0.000 pkg_resources.py:494(__iter__)

By caching the iter_entry_points call in builder ModuleRegistry, the
execution time drops from 26s to 18s.

Can be further improved by caching the whole group on first lookup and
hold in the cache if entry point in a dict.

Change-Id: Iadc60a805f7690e8388d87f52760a9f6fcd2a53e
raise JenkinsJobsException instead of Exception

Normalize all exceptions to be JenkinsJobsException from the
jenkins_jobs.errors module.  This patch replace all occurences of the
build-in Exception.

Change-Id: I923ec35467dd93211d8cd1e6c69c0321d9391ec8
Corrected typo in example for pipeline plugin

Change-Id: I82732551f9a6c8375f8a87bf0f66fb97ec0c3df1
Merge "Deprecate projectName setting of CopyArtifact"
Add support for batch_tasks.

Change-Id: I6cb6050322f07e90eadff88acab61c9ed66221fe
Merge "ModuleRegistry now caches entry points lookup"
Merge "Add support for batch_tasks."