daemon: initialize memory when handling DeviceList params

When dealing with DeviceList parameters, the generator produces code
similar to the following:

  CLEANUP_FREE_STRING_LIST char **devices = NULL;
  [...]
  devices = malloc (sizeof (char *) * (args.devices.devices_len+1));
  {
    size_t i;
    for (i = 0; i < args.devices.devices_len; ++i)
      RESOLVE_DEVICE (args.devices.devices_val[i], devices[i],
                      , goto done);
    devices[i] = NULL;
  }

The block hidden within the RESOLVE_DEVICE macro is supposed to
assign something to devices[i]; on the other hand, the code in
RESOLVE_DEVICE can cause to just end (with an error) the current RPC,
which would cause the cleanup of the "devices" array... whose members
from the i-th to the (args.devices.devices_len-1)-th would be garbage
pointers, causing random memory to be free'd (and thus crashing the
daemon).

Avoid the access to garbage memory just by having a cleaned "devices"
array, so there will be always a NULL element after the initialized
members.

Add a test for vgcreate which passes a wrong device path causing the
situation above, to test that vgcreate would fail gracefully.
tests: c-api: do not crash w/ missing hash entry

If an hash does not have the requested key, just error out cleanly
instead of crashing when trying to compare a null string.
daemon: blkid: fix memory issues in "no -p/-i" mode

Fix the memory issues in the implementation that uses no -p nor -i:
- use add_string_nodup to add results from get_blkid_tag (which returns
  new strings), so those strings are not leaked
- use free_stringslen to clean the hash on error, as in such case the
  stringbuf will not be terminated with a null entry, thus causing
  free_strings to crash
daemon: add CLEANUP_CLOSE

Just call close on the specified fd, if valid.
daemon: use CLEANUP_CLOSE
df: unlock retire_mutex on early exit

If pthread_cond_wait fails and the thread worker ends, make sure to
unlock retire_mutex, which has been locked for the condition.

The return value of pthread_mutex_unlock is ignored, as there's nothing
that can be done with it at that point.