wstream: write completion callback

Now modules using the wstream can find out what's happening to their writes.
wstream: allow empty release wbuffer cb

Sometimes a wbuffer is not supposed to be free()'d (such as when it comes
from a constant (possibly static) string, for example.
job: add in-pipe notification and closing support

- One can now manually close the in-pipe, without having to tear down the
  job.
- One can be notified of write success/failure.
os/shell: implement os_system

With the goal to support pipe-only system() calls.

Notes on the second (vim) argument to f_system() (i.e.: redirected input)
and its implications:

- When calling system('cat -', ['some', 'list']), vanilla vim (before a
  recent patch that added support for passing lists) just passes an empty
  file to the process. This is the same as immediately closing the pipe,
  which os_system does when no input is given. If we wouldn't close the
  pipe, the process will linger forever (as is the case with `cat -`).

As of now, it's not allowed to pass a non-NULL pointer as the `output`
parameter. In other words, it's not possible to signal disinterst in the
process output. That may change in the future.
eval: reimplement f_system() on top of os_system()

This evades the tempfile problem (unless of course one manually adds
redirects to the shell commandline, which some plugins seem to do, e.g.:
vim-easytags).
job: increase JOB_BUFFER_SIZE to 0xFFFF

It used to be 1024 bytes, which is very tiny and slows down some operations
(imaging `cat`-ing a large file). Benchmarks show a large speedup for such
cases. ref #978.

For modern systems 0xFFFF bytes (65535 B = 64 KB = 0.0625 MB) per job
shouldn't be a big problem.
rstream: remove 'reading' struct member

Not necessary, as discussed in #980.

From the libuv mailing list:
https://groups.google.com/forum/#!topic/libuv/OD38PeGeVgQ

E.g. this could happen (red: on Windows):

> > alloc_cb(handle1);
> > alloc_cb(handle2);
> > read_cb(handle1);
> > read_cb(handle2);

But this couldn't:

> > alloc_cb(handle1);
> > alloc_cb(handle1);
> > read_cb(handle1);
> > read_cb(handle1);

Because each stream has a 1-to-1 correspondance with a libuv handle. The
code removed was never executed.

Closes #980.
test/formatc: improve 'inline' function handling

Apple seems to define some functions as `inline` but not `static` in
headers. The ghetto parser wasn't unbelievably happy with this.
test/formatc: improve standalone usage

Easier testing.
test/helpers: allow interning Pascal strings

os_system() returns a Pascal string, for example (it also NUL-terminates the
string, but that's neither here nor there).
test/shell: add tests

- The calls to (partially) initialize logging
  need to go. Blocked on #981.