See:

 - https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/
 - https://hynek.me/articles/testing-packaging/
 - https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure

This should help avoid packaging tests.  Tests are useful for
developers, not consumers of the package.

Flit won't add both fabrictestbed_fablib and fabrictestbed_extensions
into the wheel package because it is stricter about packaging.  This
is normally a good thing.  However, we want to be able to have some
backward-compatible imports at least for a while, so we will switch to
setuptools as the build backend.

Because, unlike flit, setuptools_scm picks up version dynamically from
Git tags and revisions.

Do not use setuptools_scm, because it adds a new thing that we will
need to get used to.  Instead we will just read the version from
__init__.py as we are used to.

See:
https://packaging.python.org/en/latest/guides/single-sourcing-package-version/

This was we can do `from fabrictestbed_fablib import FablibManager`
etc.

This will avoid a circular dependency with init