Building variable fonts from non-default layer sources

Following up from #980 and [this comment](https://github.com/googlefonts/fontmake/pull/980#issuecomment-1438259929) from @anthrotype. The current code works for bulding static, interpolated instances from masters that are on a non-default layer, but fails to build variable fonts of the same kind. The first error I encountered is this:
```
fontmake: Error: In 'sources/testfamily.designspace': Generating fonts from Designspace failed: "'name' table not found"
```
That’s an error that comes from `ufo2ft` and I believe it is due to a wrong assumption of considering non-default layers as being meant for sparse master support. Layers, as defined in the UFO spec, don’t have these semantics; they are meant to be generic and used for anything, including the use case we’re trying to support here.

So when `ufo2ft` sees a master that has a `layerName` it actually strips a bunch of tables from the intermediate TTFont it’s generating internally. The tables that are allowed to pass through are defined by the [`SPARSE_TTF_MASTER_TABLES`](https://github.com/googlefonts/ufo2ft/blob/543874e2c78579905c97fff3808d71b1418d07d3/Lib/ufo2ft/constants.py#L3) constant (and likely its *OTF variant, right below.)

I tried adding the missing `cmap`, `OS/2`, `hhea`, and `name` tables to the constant, and the error goes away. Indeed, the whole `ufo2ft` and `fontmake` test suites pass with these back on, so I’m not clear why they are being stripped in the first place. Perhaps @anthrotype can comment, since he seems to be the author of the original list.

Anyhow, after that is fixed, another issue surfaces. While building the variable font, right after the master fonts are loaded and before starting to add various variation tables, the `varLib` model seems to get confused and, for a family with three masters on a width axis, returns locations that look like this:
```
[{}, {'wdth': -1.0}, {'wdth': 1.0}]
```
In other words, the default location goes missing and `varLib` errors out with:
```
fontTools.varLib.errors.VariationModelError: Base master not found.
```
So the bug appears to be inside `fontTools.varLib` rather than `fontmake`, although I guess we can track it here.

I am not entirely sure what is happening, though, and am a bit in the dark on `varLib` internals so will need some more time to dig this out.