doc: convert the documentation to the block format

The syntax overview no longer describes a line-based format, since that
is not what the rest of the documentation shows.  It now covers the
grammar, the two naming conventions, the nine aliases, and the leading
'-' on a path, and it says plainly that both formats are still read and
told apart per file by content.  Without that, a reader with an
existing configuration is left wondering what happened to it.

service-opts.md was a list of modifiers to place between a directive
and its command, so it needed rewriting rather than translating: there
are no positions left to describe.  It is now grouped by what the
settings do.

conditions.md needed correcting.  It presented '!' as a condition
prefix alongside '~'.  It is neither a condition nor a negation, it is
a flag on the block that means one thing on a service and another on a
run or task, so it is spelled reload-signal and required here, and the
page maps the old form to both.

Two things the pages claimed are not true.  The kill delay range is
1-300, not 1-60, and stop and reload scripts are no longer run without
a timeout.

ChangeLog.md keeps its line-based examples.  Those sit in historical
release entries, and rewriting them in a syntax that did not exist at
the time would misdate the format.

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

doc/example.md

@@ -98,29 +98,52 @@ Some components are optional: runlevel(s), condition(s) and description,
 making it easy to create simple start scripts and still possible for more
 advanced uses as well:
 
-    service /usr/sbin/sshd -D
+    service sshd {
+        command = "/usr/sbin/sshd -D"
+    }
 
 Dependencies are handled using [conditions](conditions.md).  One of
 the most common conditions is to wait for basic networking to become
 available:
 
-    service <net/route/default> nginx -- High performance HTTP server
+    service nginx {
+        description = "High performance HTTP server"
+        conditions  = { "net/route/default" }
+        command     = "nginx"
+    }
 
 Here is another example where we instruct Finit to not start BusyBox
 `ntpd` until `syslogd` has started properly.  Finit waits for `syslogd`
 to create its PID file, by default `/var/run/syslogd.pid`.
 
-    service [2345] log <!pid/syslogd> ntpd -n -N -p pool.ntp.org
-    service [S12345] syslogd -n -- Syslog daemon
+    service ntpd {
+        runlevel      = "2345"
+        conditions    = { "pid/syslogd" }
+        reload-signal = "none"
+        log { }
+        command       = "ntpd -n -N -p pool.ntp.org"
+    }
 
-Notice the `log` keyword, BusyBox `ntpd` uses `stderr` for logging when
-run in the foreground.  With `log` Finit redirects `stdout` + `stderr`
-to the system log daemon using the command line `logger(1)` tool.
+    service syslogd {
+        description = "Syslog daemon"
+        runlevel    = "S12345"
+        command     = "syslogd -n"
+    }
+
+Notice the empty `log` block, BusyBox `ntpd` uses `stderr` for logging
+when run in the foreground.  With it Finit redirects `stdout` +
+`stderr` to the system log daemon using the command line `logger(1)`
+tool.
 
 A service, or task, can have multiple dependencies listed.  Here we wait
 for *both* `syslogd` to have started and basic networking to be up:
 
-    service [2345] log <pid/syslogd,net/route/default> ntpd -n -N -p pool.ntp.org
+    service ntpd {
+        runlevel   = "2345"
+        conditions = { "pid/syslogd", "net/route/default" }
+        log { }
+        command    = "ntpd -n -N -p pool.ntp.org"
+    }
 
 If either condition fails, e.g. loss of networking, `ntpd` is stopped
 and as soon as it comes back up again `ntpd` is restarted automatically.