7988: log administrative actions on the monitors

We mean to log every administrative action performed on the monitors.

This means logging to a permanent medium any commands handled by the monitors,
may they be via 'ceph' tool commands ('ceph auth get-or-create-key...') or via the
admin socket.

For this effect we added a new LogClient to the monitor, to which we will log key
administrative actions (just like we currently do for the cluster log).

We add a few new options to enable/disable administrative logging to syslog, as
well as syslog level and facility (defaulting to 'no logging to syslog' (i.e., false),
'info' and 'local0', respectively).

It should be noted however that although the above options have been added
to Ceph, they are used by the Monitor class when initializing the 'admin_clog'
field (class LogClient) and not directly used by LogClient itself.  Instead, we
abstracted LogClient such that it will by default keep on using the usual clog
options, while allowing to be explicitly provided with a facility and a level.  The
way we do this is however somewhat ugly -- we pass on pointers to the config
options -- so that we are able to modify the options in-flight without having the
LogClient become a config observer (which in turn would require the LogClient
to be aware of the options variables).  A neat side effect of this is that we have
the LogClient becoming independent from the Context's options, allowing us
to provide whatever variables we want regardless of Context (I admit I hardly
find a *sane* use case for this).

The reader will notice that we barely register any actions whatsoever.  We opted
to keep the whole thing simple, thus taking advantage of the monitor's command
handling functions and callbacks: we log dispatches as they come in, only for
commands (we don't want to log anything besides administrative actions and those
come in the form of commands to the monitor), and we will also log command
completions -- via Monitor::C_Command.  Once we log and dispatch a command,
we will not log if the command aborts nor if it has no effect.

We will however do our best to log commands via the admin socket.  We fear
that the output of said commands may be a bit weird, as we have no way to output
a list of arguments in the order supplied to Ceph (command arguments come in the
form of a map, not a list).  Although it currently works fine for the set of admin socket
commands supported by the monitor, this may not be in the future.

Also, to be noted, we do not handle admin socket commands that are not handled by
the monitor.  Commands such as 'config set' or 'config get' will be handled directly by
the upper layers of the AdminHook, to which we don't currently have access to.