Decide how to store font info in D8

D7 answers to these questions are No, Yes, and No. My initial, mostly uninformed, thoughts on D8 answers: Yes, No, Yes.

On #3 first, using the new configuration management system would make it really easy to move font settings from one server to another, a problem we're currently solving with Features integration. This might also replace the way we're doing theme integration, as themes could include default font configurations.

On #1, mapping fonts to entities seems pretty obvious. Font tags can be a taxonomy field, and pretty much everything else can be a property. The font reference field could be replaced with entity reference, and all the queries could be simplified as entity field queries.

If the above answers are correct, then it seems like we no longer need custom database tables for storage, so that answers #2.

My main question on this is what happens with Views integration if we do it this way. Does Views integration work with entities stored only as configuration? If so, what does that look like? Looking through what D8 core does currently, I don't see an answer to this. The only entity type I see that is saving in configuration is views, and Views doesn't use itself to list views. Instead, it uses entity_list_controller(), which looks much more limited than what we're currently doing in font lists with Views. If that turns out to be the only option, this may be enough to back out of all of this and stick with the D7 custom table approach.

On further research, ConfigEntityBase says "configuration entities are not fieldable." So our choices are between a config entity and a field-able entity. A config entity is easy to move, and a field-able entity is easy (possible) to query (e.g. with Views). I think we probably need to maintain both moving and querying of fonts. Since we can do moving without config, and we can't do querying with config, I'm changing my answers to Yes, Yes, No.

I think what this means for code is we keep the fontyourface_font table, create an entity type that uses everything in that table as properties, and move tags to fields. If we do providers as bundles (or "subtypes"), then we could probably also move a lot of the metadata into provider-specific fields and make that query-able as well.

I'm going to leave this open until it's actually implemented, since implementation might introduce new complications here.

Fonts are now working as fieldable entities with providers as bundles. Providers are config entities. This is far enough along now that I'm faily confident it's going to work, so I'm marking this as done.