* Move relevant code from CcTrayStatus#jobStatusChanged and dependencies to CcTrayJobStatusChangeHandler.

* Move relevant code from CcTrayStatus#stageStatusChanged and dependencies to CcTrayStageStatusChangeHandler.

Change the interface of CcTrayJobStatusChangeHandler so that it can be
used by the config change handler too, since it needs to convert Job
instances to ProjectStatus.

Change the interface of CcTrayStageStatusChangeHandler so that it can be
used by the config change handler too, since it needs to convert Job
instances to ProjectStatus.

* Stages already in cache are used.
* If they're not in the cache, then the DB is queried.
* If a stage in not in DB as well (never run), then a dummy stage status is used.
* Handles new jobs in config (converted to dummy state) and removed jobs (removes from cache).

Breakers are calculated as before. This is almost a full migration from
CcTrayStatus#computeBreakersIfStageFailed to CcTrayBreakersCalculator.

Almost a migration from old CcTrayStatusService#initializeMissingStages method
to CcTrayStageStatusLoader.

CcTrayStageStatusLoader needs to load a stage from DB. But, it causes a circular dependency
if it uses StageService, because StageService needs all StageStatusListener objects during
construction. CcTrayActivityListener is a StageStatusListener, which depends on
CcTrayStageStatusChangeHandler, which is a dependency of CcTrayStageStatusLoader (circular).

Flattens out group and superadmin user and role permissions into a map of
pipeline groups to the set of users who can view them.

Depending on the view permissions of the pipeline group, update each CcTray project
status with the viewers, so that they need not be checked every time.

Prevents config from having to be iterated on, to get projects.

* Consider user permissions (who has access to a pipeline).
* Generate XML and cache parts when possible.

Unlike the job and stage status change listeners, the config change listener requires
explicit registration. Hook up CcTrayListener to ApplicationInitializer, to guarantee
order of registration.

When a job or stage changes, the cache is updated with the new status. But, the orderedEntries list
was not updated, since it was maintained externally. Now, use a LinkedHashMap to to maintain order.

When a job or stage status changes, the existing view permissions in cache should be
preserved. That information changes only when config changes.

* The CcTrayActivityListener queue processor is now started during initialize.
  Otherwise, it won't process anything.

* Also, mark the orderedEntries field in CcTrayCache as volatile, since it is
  accessed by multiple threads and changed by one.

* Provide route in Rails to new_cctray.xml (temporary route name).
* Use context and request paths to decide on correct prefix (as was done
  with old CCTray requests).

A value passed to localize was nil. Set it to a valid value in the spec.

Without this change, it redirects to login page. Compare:
curl -I 'http://localhost:8153/go/cctray.xml'
curl -I 'http://localhost:8153/go/new_cctray.xml'