Rethinking the gftools/fontbakery boundary

This is inspired by something @m4rc1e said elsewhere:

> When we finally get gftools imported into fb as a dependency, we'll have easy access to the GF glyph sets/encodings.

This creates a situation where:

* gftools depends on fontbakery for running QA tests (`gftools qa`)
* fontbakery depends on gftools for data

A mutual dependency is obviously a Bad Thing from a practical point of view. But from an architectural point of view, it's actually a Good Thing because it forces us to re-evaluate the boundary between the two packages!

Let's step back and think about what is in each package. I'm reminded that @graphicore has often argued (see [here](https://github.com/googlefonts/fontbakery/issues/3188#issuecomment-802887846) amongst other places) that fontbakery is a very generic check runner which provides cool things like dependency injection and profiles and so on, and that nothing should happen to the fontbakery check runner that makes it more font-specific. And that's good. I agree!

But it means we currently have:

### fontbakery

* generic check runner
* knowledge about diagnosing font problems
* some miscellaneous font metadata (e.g. `fontbakery.constants` includes style names, licensing text, name/encoding IDs, GF Latin core glyph list...)

### gftools

* knowledge about how to *fix* font problems (often the same problems diagnosed by fontbakery)
* assorted font-related tools
* some miscellaneous font metadata (e.g. `gftools.util.styles` includes style names, `gftools.constants` includes name/encoding IDs, `gftools.encodings` includes GF Latin core glyph list...)

How can we arrange these different things to encourage code reuse and reduce mutual dependencies?

Here's my suggestion. The suggested package names are *terrible* but you'll get the idea:

### thebakery

* generic check runner

### gfdata

* a "data-only" module similar to [opentypespec](https://pypi.python.org/pypi/opentypespec) which contains all the font metadata we use.

### fontdoctor

(requires gfdata)

* knowledge about how to diagnose font problems.
* knowledge about how to fix font problems.

### fontbakery

(requires fontdoctor and thebakery)

* Font QA engine (diagnosis/testing only)

### gftools

(requires fontbakery, fontdoctor and gfdata)

* assorted font-related tools
* front-end CLI utilities to call fontbakery
* front-end CLI utilities to call fontdoctor fixes