Major change, rename <svc/...> conditions to <pid/...> conditions

The <svc/foo> condition was created to synchronize starting services,
hence the abbreviation.  Example: the Quagga ripd needs to start after
the zebra daemon to ensure its UNIX domain socket is active, otherwise
events may be lost.

However, considering that synchronization was implemented with UNIX PID
files, e.g. waiting for /var/run/quagga/zebra.pid to be created, the
condition abbreviation name <svc/foo> was hard to understand by most
newcomers to Finit.  To make matters worse, a new feature to track or
even create PID files for services that don't create one themselves,
using the syntax 'pid:/path/to/foo.pid' was added.

Connecting the dots between these wasn't obvious.

This patch renames service conditions pid conditions and also adds
a compatibility wrapper to the Finit .conf parser.  Any condition
given in old .conf files with 'svc/' prefix are internally renamed
'pid/', along with a LOG_INFO notice in syslog.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

doc/config.md

@@ -184,7 +184,7 @@ Syntax
   from forking (daemonizing):
 
 ```shell
-        service [2345] <svc/sbin/zebra> /sbin/ospfd -- OSPF daemon
+        service [2345] <pid/sbin/zebra> /sbin/ospfd -- OSPF daemon
 ```
 
   The `[2345]` is the runlevels `ospfd` is allowed to run in, they are
@@ -206,7 +206,7 @@ Syntax
   For example, by adding `pid:/run/foo.pid` to the service `/sbin/bar`
   that PID file will, not only be created and removed automatically, but
   also be used by the Finit condition subsystem.  So a service/run/task
-  can depend on `<svc/sbin/foo>`, notice the composition of conditions.
+  can depend on `<pid/sbin/foo>`, notice the composition of conditions.
 
   However, if a service `bar` *does* create a PID file, using `foo.pid`,
   we can inform Finit of this by prepending an `!`: