6.5.4 and earlier supported --logfile="|..." to indicate logs should be piped to another process.

This no longer works with 7.0a. There are a bunch of problems:

0. A bug in addLogAppender:

        if ($filename =~ s/|//) {

                $filemode = 'pipe';
        }

   That regexp should be s/^\|// (ie quote the | and anchor to start). This small program
   shows the problem:

   $s="x";
   print "Surprise\n" if ($s =~ s/|//);

1. _defaultAppenders uses serverLogFile(), scannerLogFile() and perfmonLogFile() which are sensitive to the
   --logfile option, but pay no attention to the leading |, leave the mode at "append", and cause
   log4perl to attempt to open a file named "|..." :-(

2. With a little bit of work, it is possible to have serverLogFile() et al strip the leading | and
   set the log mode to "pipe". This doesn't have the desired effect because this spawns _three_
   processes (one each for the server, scanner and perfmon) and all compete to write to the
   log directory --- urk --- a mess all around.

3. Essentially the semantics are broken. In 6.5.4 the semantics of --logfile="|..." is that
   a single process should absorb all the log output. In 7.0a, there are three logs: server,
   scanner and perfmon. The most obvious interpretation is that --logfile="|..." should
   multiplex server, scanner and perfmon into the one process.

   The problem is that each log is specified as a separate appender. It's not clear to me
   if it's even possible to multiplex these logs together using log4perl.

The simplest fix might be to only use $::logfile for serverLogFile() and remove references to
it from addLogAppender(), scannerLogFile() and perfmonLogFile(). Then fix serverLogFile() to
allow for both "append" and "pipe" by introducing serverLogMode().

                'server' => {
                        'appender' => 'Log::Log4perl::Appender::File',
                        'mode'     => 'sub { Slim::Utils::Log::serverLogMode() }',
                        'filename' => 'sub { Slim::Utils::Log::serverLogFile() }',

The downside of this fix is that --logfile only specifies the server log. All other logs go their
separate ways.