The SCM polling for a job continues even while the job is already queued up from
a previous polling operation.

This means that the polling log no longer reflects why a build was scheduled,
but rather why it would now be scheduled, which may be subtly different.

In addition, it means the load on the SCM system caused by polling (which
should be low, but may not be) continues even when it isn't needed to trigger
a job to be built.

I recommend we at least add option to SCMTrigger to disable polling while:
a build is queued up for the job;
a build is running for the job.

As far as I'm concerned, those behaviors could be baked in (i.e. not options),
but others may like the current behavior.