alarms: add fuller support for Markers

Recently it was discovered that one of the alarm definitions
(for checksum) was out of sync with the code because the logging
statement it was based on had been modified and this modification
had gone undiscovered (see patch https://rb.dcache.org/r/7115).

The bug brought home the point that reliance on the remote-server
filters can be fragile. While it is desirable to continue to
support these filters, a more robust policy in terms of
development would be to make all such filters optional and
generated by admins. This would mean that all predefined
alarms (introduced by developers) should code them directly
via the alarm Marker provided for.

Currently, however, all such alarms end up being generic, and
their severity level is determined by the logging level at
which they are emitted. This situation is not optimal, as
developer-defined alarms should be capable of the same
finer-grained distinctions (severity and type) as are
permitted by the XML definitions processed on the remote end.

In anticipation of a subsequent patch converting all the
currently predefined alarms into alarms emitted directly
using a marker, this patch extends the internal alarms
API in order to support more fully the definition of
such code-driven alarms.

The main changes introduced by this patch are as follows:

1)  Fuller API for producing an Alarm Marker is provided.
    The main method now takes three parameters: severity,
    type, and key. An alarm marker thus consists of
    a principal marker (ALARM), plus two required
    attribute markers (severity, type) and one optional
    (key, allowing one to determine whether two alarms
    of this type are to be considered identical) whose
    actual values are submarkers of each.

    The creation of markers has now been moved to a static
    AlarmMarkerFactory, and this, plus the basic interfaces
    have been moved to dcache-common for availability
    everywhere.

2)  Extraction of these attributes to create a LogEntry
    has been modified accordingly.

3)  The dcache alarm send command has also been adjusted
    so that -l now denotes Severity level, not logging level.
    All alarms generated by this command are now sent at
    the error level; they are all still without a key,
    meaning each instance is considered to be a different
    alarm. The man page has also been updated.

4)  Because incoming alarms that have already been
    marked as such (and are not in need of being
    matched to a definition) now carry fuller type
    information, the current webadmin alarms page
    also needed modification. The drop-down box
    allowing one to filter the table entries
    currently carries the list of all alarms
    defined in the alarms-definition.xml. This
    has always had the disadvantage of requiring
    a copy of this file to be on the http server
    node as well as the node where the remote
    alarm server is running. But since this
    list no longer represents all the currently
    defined alarms, the usefulness of displaying
    that drop-down list based on that file has
    diminished.

    A compromise has been adopted here: instead
    of trying to display all the possible alarms,
    we have opted to display a list of all types
    which are "known" to the underlying store:
    that is, all types which have thus far been
    sent. One may thus suppose that if a particular
    type of alarm does not appear in the list,
    it has not been received (yet).

    In order to support the extraction of this
    list through the DataNucleus layer, we have
    used a JPA-like (JPQL) query run each time
    a load of the combo-box is called. Since there
    is already an index on the type attribute,
    the query should not cause severe response
    problems.

    We have also adjusted a few minor inconsistencies
    in the logging inside the DataNucleusAlarmStore
    and have eliminated the webadmin-specific
    alarms definition file path, since it is now
    unused on the httpd end.

5)  I have also eliminated the ChecksumAlarm simulator;
    this class was never really used and is in any case
    not necessary.)

Testing:

With RDBMS connector:

Tested production of alarm using dcache alarm send.
Checked the webadmin alarms page for proper loading
of the combo box.

With XML connector:

Same procedure. Works.

RELEASE NOTES

The "-l" option on the dcache alarm send command now takes a Severity level
rather than logging level.

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