alarms: convert definitions into marked alarms

Replaces the remaining server-side alarm definitions
currently shipped with an alarm marked at the point
of emission (the database-connection-related alarms
were taken care of by patch 7138).

Target: master
Patch: https://rb.dcache.org/r/7137/
Require-book: yes
Require-notes: yes
Acked-by: Tigran

BOOK:
RELEASE NOTES:

All predefined alarms which were previously shipped
as alarm definitions are now embedded in the code.
These are also given specific types, severity levels
and even unique keys, just as the xml definition
allows.

The procedure for generating a custom alarm definition
has remained unchanged, so sites can continue to augment the
number of errors to be marked as alarms via the alarms-
definition.xml file.

The web page filter box for string matches
no longer carries as a drop-down all predefined
alarms, since there are now many alarm types
that are "hidden" in the code itself. What is
displayed as a drop-down list are any and all
types currently in the data store (hence if
a known alarm type does not appear in that list,
it indicates that no alarm of that type has
been received or at least remains recorded in
the store).

The dcache alarm send command option '-l' now
refers to the Severity (CRITICAL, HIGH, MEDIUM
or LOW) and not to the logging level.

As a rule, one can expect that any alarms envisaged
by the developers will be of the embedded type,
and any alarms defined in the alarms-definition.xml
file will by subject to verification by the site
administrators (since they depend on logging
statements, care must be taken to make sure
they continue to match).

Because the alarms-definition.xml file is no
longer used to create the web page drop-down
list, a copy of it is no longer necessary on
the node running the httpd service. The
corresponding path property has been dropped
from the httpd.properties (defaults).