Improve site states functionality

The possible site state list has changed, the Finalizing state doesn't exist anymore.
There is a new state labeled 'Aborted'.

Normal state functionality has no changes.
Draining state doesn't pull work for existing workflows anymore into the local queue.
Down state funcionality has no changes

Aborted state:

This new state indicates that a site is in error state and won't be recovering soon,
the best approach then is to kill any job at the site and fail any jobs that can only
run there since it is not efficient to wait until the site comes back or the input
for these jobs is lost at the site.

- If a site is in Aborted state, the JobSubmitter will not use it for submission.
  Moreover if a job can only run at an Aborted site then this job will go into
  submitfailed state with errorCode 61102.
- When a site is changed to Aborted state, all the jobs currently assigned to that site
  in the batch system will be killed, the error code for this is 61301. These jobs
  will follow usual WMAgent retry mechanics which means cooloff/resubmssion. Note
  that when resubmitted they will fail if they can't run anywhere else as stated above.
- For WorkQueue purposes an Aborted sites behaves as a Down site.

Additionally to support this functionality, there are changes in the ErrorHandler to improve
the smart error handling, now there are certain not-configurable errorCodes which cause
immediate exhaustion of the jobs. 61301 is the only one as of now and also if a report
has no time information it will now check the exit codes before deciding the fate of the job.
The ErrorHandler now reads FWJRs by default and has a default maxFailTime of 32h.

The error codes are now contained in WMExceptions.py, just a few of them now. But more
will be added later to keep them documented.

Finally, the JobSubmitter now resets the cache when a site changes state, this is to
ensure that the jobs are assigned correctly according to site availability at all times.
Although it can make the JobSubmitter slower on agents with a large number
of created jobs, however site state changes are not frequent so this is tolerable.

Fixes #4408
Fix prioritization of tasks

The tasks priorities in batch level were being taken from a task
value that was not set for all tasks and also was static to
5 for Merge/Cleanup/Harvest and 0 to Processing.

ResourceControl allows dynamic priorities per site and task type,
this patches changes the submitter to use those instead and
remove the signature of WMTask.taskPriority since it is not
needed anymore.
Check for run/lumi info in CMSSW outputs

All outputs from the CMSSW step should have run/lumi information
from the cmsRun process. Verify that and if not present
fail the job.

Fixes #4416