srm: Align SRM info output with recent changes to scheduler configuration

In 2.10 the SRM scheduler configuration was reimplemented together with several
internals. The info output however retained all the old configuration
parameters. These make no sense given the new configuration parameters and the
way the scheduler works now.

This patch rectifies this by showing information that pertains to the current
scheduler implementation.

The new format looks like this:

--- scheduler-put (Scheduler for PUT operations) ---
    Queued ............................     0     [TQueued]
    Waiting for CPU ..........     0              [PriorityTQueued]
    Running (max 250) ........     0              [Running]
    Running without thread ...     0              [RunningWithoutThread]
    Waiting for callback .....     0              [AsyncWait]
    In progress (max 50) .....   SUM >>     0
    Waiting for retry .................     0     [RetryWait]
    Queued for transfer ...............     0     [RQueued]
    Waiting for transfer (max 2000) ...     0     [Ready]
    ------------------------------------------
    Total requests (max 10000) ........     0

    Soft limit by same owner : 100
    Retry timeout            : 60000 ms
    Retry limit              : 10

It shows a descriptive text in each state, together with the number of requests
in each state and the actual internal state. The states that have limits show
this limit in the descriptive text, making it easy to see which states are
limited. Indentation is used to show how in-progress is the sum of several
states.

I made some small related refactorings to make Scheduler and Configuration
implement CellInfoProvider (through sub-classing in the dCache specific
modules). This provides nicer info output with descriptive headings.

I had to fix some bugs in UniversalSpringCell to allow several bean instances
of the same class.

Target: trunk
Request: 2.10
Require-notes: yes
Require-book: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7231/
chimera: do not explicitly remove enties in t_level_x

as DB takes care about it.

Acked-by: Gerd Behrmann
Target: master
Require-book: no
Require-notes: no