New functionality allowing one project's trigger to depend on others'.

This feature adds a Project Dependency system to the gerrit trigger
plugin. In the advanced section of the trigger, it is possible to add
projects as "dependencies" (a check for cycles is performed at that time
to prevent depending on something which depends on self).
There is an auto-complete functionality.
If such a dependency project is added, then when a gerrit event happens
which should trigger both the project and its upstream dependency, the
new QueueTaskDispatcher will wait for the upstream to finish before
building the downstream project.

Known limitation: in "normal" situations, the dispatcher must assume
that all projects are triggered before any build is considered in the
queue by Jenkins to check if it canRun(). This is usually the case
because of a "quiet" period of 3 seconds allowing triggering to
complete, even for a large number of projects, before queue is
processed.
For the RetriggerAll action and ManualPatchsetCreated, this limitation
is not present as there are hooks allowing to guarantee that all
projects are triggered before consideration of the queue.
Moved files to follow new plugin src architecture.

Also removed unused lines, and changed constructor parameter to
GerritHandler rather than HandlerLifecycle as this was overkill.
Various improvements for extension hardening and more unit tests.

- Defensive NPE protection around possible null GerritHandler
  (future-proofing)
- Moved synchronization into a "ConcurrentHashSet"
- Added unit tests for the form validation (cycle detection)
- Added check that the QueueTaskDispatcher barrier was being called in
Gerrit Trigger
Merge pull request #139 from yannack/dependentGerritProjects

New functionality allowing one project's trigger to depend on others'.