Calling norns(ctl)?_error() to query the status of a running task will
release its descriptor in the server if the task already completed
(NORNS_EFINISHED or NORNS_EFINISHEDWERROR). Since norns(ctl)?_wait()
internally queries the task status to check whether a task has
completed, we cache the retrieved task_status into the iotask_t user
descriptor so that it can be retrieved by a subsequent
norns(ctl)?_error() call.

Merge branch '28-norns_wait-nornsctl_wait-should-accept-a-second-parameter-to-specify-a-timeout' into 'master'

Resolve "norns_wait()/nornsctl_wait() should accept a second parameter to specify a timeout"

Closes #28

See merge request !12

Functions norns_wait() and nornsctl_wait() now accept an optional
const struct timespec *timeout (see nanosleep(2)) to allow users
to suspend the calling thread until one of the following occurs:

* A signal is delivered and the task has already completed.
* The specified time interval has already passed.

If timeout is NULL, the functions will suspend the thread for
a predefined amount of time and query the server upon waking up.

Note that since the server does not allow registering listeners at the
moment, the thread will wake only when one of the aforementioned
conditions has occurred, even if the task of interest has already finished.

Resolve "Spurious SEGFAULTs with libtar"

Closes #27

See merge request !11

Resolve "Add nornsctl_* functions for tasks"

Closes #25

See merge request !10

Add nornsctl_iotask_init()
Add NORNSCTL_IOTASK()
Add nornsctl_submit()
Add nornsctl_wait()
Add nornsctl_cancel()
Add nornsctl_error()

We need to provide a nornsctl_status() function to check the status of
administrative data transfer tasks, but we already have
a nornsctl_status() function in the API that checks the global status of
the service. Thus, we decided to keep the current nornsctl_status() and
rename norns_status() to norns_error() and provide a nornsctl_error()
for simmetry.

Resolve "Add support for remote transfers"

Closes #21 and #24

See merge request !8

Transfer plugins now receive a new 'context' object that provides access
to relevant data structures from the daemon. This way, they can query
information about the current configuration and status without directly
involving the daemon object.