This is a start of the conversion of the ZFS backend to libzfs_core /
pyzfs.

The helper wraps lzc functions but also provides a method to schedule
any function without creating a wrapper.

Currently a thread pool of a reactor is used, but a dedicated pool could
be used.  Test reactor(s) without a thread pool are also supported.

Also, remove all unit tests for snapshots.
The unit tests were based on the fact that the operations were done via
zfs command, so they checked that the command was spawned with the correct
arguments and the output was correctly parsed.

To do:	invent the way to test the new implementation

Note that lzc_create() never mounts the filesystem.
'zfs create' used to mount the filesystem, so now we have to do that
explicitly and at the moment that is done via 'zfs mount'.

Note: lzc_send()/lzc_receive() do not close their end of the pipe
(the file descriptor, in general) when they are done writing to it.

Note: this API is synchrnous at the moment including a requirement
for a synchronous cleanup of the file descriptors.
There are functional tests to verify that.

The properties are readonly and mountpoint properties.
Note that one thing that all these operations have in common is that
they may require a dataset to be unmounted and/or mounted.

In theory two snapshots can the same 'creation' time because its resolution
is on second.  In fact, I've seen a test failing because of that.
createtxg is always unique, because ZFS does not allow to created more
than one snapshot for the same filesystem within the same transaction
group.

Also, internal _list_filesystems() method is changed to return an iterator
rather than a deferred that produces an iterator.
It's not clear why we need the iterator at all because the single user
of this method consumes the whole iterator and builds a set.

Note: that we need to explicitly unmount the filesystem before
destroying it.

…core

_sync_command_error_squashed() became obsolete and was removed.
Its unit tests are removed as well.

'zfs umount' refuses to work on a ZFS filesystem if its mountpoint
property is set to legacy or none.  On the other hand, 'umount'
can handle all property settings.  So, prefer using the latter.

The ZFS backend itself never sets mountpoint to those values, but
there is at least one funcitonal test case that sets up a requried
scenario by directly fiddling with the property.

To implement the change zfs_command() function is split into
ext_command() that can handle any external command and zfs_command()
convenience facade.

deferLater() unlike maybeDeferred ensures that the reactor is
actually running.  This is required by the new ZFS backend, because
it uses the reactor's thread pool to run lzc_send() and lzc_receive()
in separate threads.  That has to be done because those calls lend
their context to the kernel for doing the actual send / receive
work.  The main thread pumps the stream data between the userspace
and the kernel.

The latter can not automatically derive a snapshot name from
the given stream.
See ZFS-30 for more details.