[entropy.misc] add shared(), release() context managers to FlockFile
[entropy.db.skel] add base API for handling flock based synchronization
[entropy.db.sqlite] add _is_memory() method
[entropy.db.skel] split release() into release_shared() and release_exclusive()
[entropy.db.skel] warn about flock related methods usage
[entropy.db.sqlite] implement locking infrastructure
[entropy.client] always prefer installed_repository() over protected attribute
[entropy.db.skel] warn when repository locks are being acquired
[entropy.db.skel] fix exclusive() wrt acquired bool
[entropy.db.skel] write locking output to stderr

This avoids breaking scriptability of --quiet options
[entropy.db.skel] improve output during lock contention phases
[entropy.const] add /run/entropy directory setup, expose it through etpConst['entropyrundir']
[entropy.db.skel] expose lock_path() and make file lock path configurable
[entropy.db.sqlite] use lock_path() instead of self._db for file locking
[entropy.db.sqlite] clear in-RAM cache after lock acquisition
[entropy.db.skel] document further locking infrastructure assumptions
[entropy.db.sqlite] drop support for locking based on rwsem for memory repositories

Firstly, rwsem is semantically different from flock (but this was known) and
this may confuse the API consumer. Secondly, the locking infrastructure is
purely meant for inter-process synchronization, threads synchronization is
not a current use case.
[entropy.db.sqlite] commit() any pending transactions on release

This avoids potential deadlocks to occur.
[entropy.client.package] install: add initial concurrency support
[entropy.misc] FlockFile: add a get_path() method