go123 update is NFC.

Since ZBigFile keeps references to fileh objects that are created
through it it forms a file <=> fileh cycle that is not collected without
cyclic GC:

https://lab.nexedi.com/nexedi/wendelin.core/blob/v0.13-52-ga702d41/bigfile/file_zodb.py#L497
https://lab.nexedi.com/nexedi/wendelin.core/blob/v0.13-52-ga702d41/bigfile/file_zodb.py#L566-571

We did not noticed this leak until now because it is small, but with
upcoming wendelin.core 2 it is important to release a fileh, because
there is WCFS connection associated with fileh, and if fileh is not
released, that connection also stays alive, keeping on-WCFS resources
still being used, and preventing WCFS from being unmounted cleanly.

-> Add cyclic GC support to PyBigFile / PyBigFileH

NOTE: we still don't allow PyVMA <=> PyBigFileH cycles to be collected,
because fileh_close called from fileh.__del__ asserts that there are no
live mappings left. See added comments for details. There is no
known practical need to use such cycles, so this should be ok.

See also other patches on cyclic GC topic:

- 450ad804 (bigarray: ArrayRef support for BigArray)  // adds cyclic GC support for PyVMA
- d97641d2 (bigfile/py: Properly untrack PyVMA from GC before dealloc)

X bigfile/_file_zodb: Fix ZSync to close not only wconn, but also wconn.wc through which wconn was created

pywconnOf, before creating wconn, performs wc=wcfs.join(zurl) which
creates new filesystem-level connection to WCFS server. This wc is used
only to create wconn. So if we do not close wc, after releaseing wconn,
it will leak opened file descriptor, to e.g. .wcfs/zurl and prevent
tests from finishing cleanly.

Its just a debugging print - helpful to debug zwatcher, but not helpful
to understand which events the system was observing.

Helps to understand why if wcfs cannot be unmounted.

Don't use regular mutex to protect _zsyncReg updates as this can
deadlock because one of _zsyncReg mutators (on_zconn_dealloc) is invoked
by automatic GC that can be triggered any time.

The logic inside ZSync was correct, but it was incorrect to attach zsync
to zconn to stay alive and react when that zconn is garbage collected:
zsync._on_zconn_dealloc was not called because zsync itself was garbage
collected too.

This fixes many failures where wconn and associated pinner was not
released even though ZODB DB was correctly closed.

This makes sure to cleanup /proc/mounts from stale / broken FUSE
connection, and removes uninformational `assert not is_mountpoint` from
raising, thus, adding more noise in already very verbose wcfs-kill-dump.

Excercise the logic that keeps wconn <-> zconn in sync.

To known to which DB state WCFS connection corresponds. This is similar
to zodb.Connection.At() in ZODB/go and to zconn_at in ZODB/py.

wconn.at() will be used in the next patch to verify ZSync.

Manaully, because there is no automatic dependency tracking in
setuptools...

Dependency tracking is needed to avoid miscompilation after incremental
update under SlapOS/buildout/testnode/... when e.g. only .h was changed.

Tests inside wcfs/ care to do this, but e.g. test.py/fs-wcfs autospawns
wcfs servers during regular bigfile tests. If we don't stop spawned
wcfs, those processes will leak, and also they keep `nxdtest
test.py/*-wcfs` in "hung" state, because nxdtest is waiting for wcfs to
stop as wcfs stdout is connected to nxdtest input.

Currently kills wcfs in abrupt way, because graceful pinner shutdown is
not yet implemented there.

tWCFS is responsible for starting/mounting/unmounting/stopping wcfs
tDB uses tWCFS and provides commit/test service on top.

We'll use tWCFS in the next patch to unmount/stop WCFS processes that
are automatically spawned during test.py

Once WCFS instance is created, use wc.mountpoint to refer to where this
wcfs is mounted. It does not change anything right now, but in a
follow-up patches we'll reuse the code from wcfs_test to work on any wc,
not neccessarily mounted on testmntpt.

Else, when runing tests intree `import wcfs` and `import wendelin.wcfs`
will give two different modules, and inspecting e.g. wendelin.wcfs at
teardown will see fresh module state (_wcregistry) because it was wcfs
which was used.

Also just `import wcfs` will raise ImportError when run out of tree.