[entropy.locks] make ResourceLock reentrant wrt to individual threads only
[entropy.locks] drop "_lock", just "acquire" or "release", it's cleaner
[entropy.client.misc] add sharedinstlock and exclusiveinstlock decorators
[entropy.client.sets] make Sets a new-style class
[entropy.client.package] synchronize text output calls to avoid garbled output

Some parts of the package actions code are now multithreaded and some
other will likely become that in the near future.
For this reason, all the TextInterface.output calls are now wrapped and
synchronized by a mutex.

Ideally, this synchronization could have gone directly into entropy.output
but I am reluctant about placing expensive locking so deep into the code at
this time.
Revert "[entropy.client.package] synchronize text output calls to avoid garbled output"

This reverts commit e722455432317516235e56fb386a60f05d237804.
[entropy.output] sychronize writes to stdout/stderr to avoid garbled output

In a multithreaded scenario, text may get garbled if there is no
synchronization between threads wrt the shared resources (std{out,err}).
This happens even when stdio buffering is enabled, of course.
[entropy.locks] make sure not to leak fds when using non-blocking calls
[entropy.locks] make sure not to leak fds when using non-blocking calls
[entropy.locks] introduce UpdatesNotificationResourceLock

This will make possible to stop available updates notifications
from being issued while an install/upgrade is in progress
[RigoDaemon] drop sleep()

With the new locking strategy, this is no longer necessary
[entropy.locks] UpdatesNotificationResourceLock: do not dictate any particular lock mode
[solo.commands.install] acquire the UpdatesNotificationResourceLock in shared mode

This will temporarily disable available updates notifications from
RigoDaemon
[RigoDaemon] use UpdatesNotificationResourceLock to avoid signal spam

If this resource lock is acquired, block until the lock is released
so that we will not keep sending status updates to the connected clients
[RigoDaemon] make sure that the serializer is always released

Even in case of exceptions.
[solo.commands.install] acquire the notification lock in shared NB mode

This should avoid starvation in the scenario outlined in code comments.
[RigoDaemon] acquire UpdatesNotificationResourceLock in non blocking mode

We cannot sleep with the activity mutex held without affecting
parallelism so badly. Otoh, we cannot wleep on UpdatesNotificationResourceLock
without affecting 3rd party clients in a way that we would starve them
for a while. So, try to acquire the file lock in non blocking mode
and if it fails, reschedule a new call as soon as the same lock is
freed (exclusive acquire succeeds). This assumes that if the lock
is held back, we will just re-do the whole trick again and again.
[entropy.client.client] add installed packages repository locking support
[entropy.client.dep] add installed packages repository locking support
[entropy.client.db] add installed packages repository locking support