Rethink conditions

[simoncozens]

This is another major refactor to the internals, which greatly simplifies the checkrunner, profile and codetester modules.

The idea is that instead of the profile containing a dictionary of iterargs, the files to be tested are stored in a CheckRunContext object. The profile is just the checks to be run. The CheckRunContext object contains a list of testables, which are Font, Ufo, ... objects.

Now conditions become a lot simpler - whenever we want to "ask a question" about one of these files (is it TTF? is it bold? is it hosted on Google Fonts?), we simply call a (cached) property on the testable object. This means there is no need to arrange for arguments to be fed to the "conditions", and chain calls to them - a property on a Font can call another property on a Font just with standard Python method dispatch. This in turn eliminates around 50% of what checkrunner.py was doing.

A nice side effect of this is that codetesting.py no longer needs to use any internal methods of checkrunner. It just constructs a context, hands it to CheckRunner and looks at the results. There is a clean "mock object" syntax for fiddling with properties of the testables to exercise different codepaths.

(As a second nice side-effect, you can turn a single input file - say a .TTC - into multiple Font objects in your CheckRunContext, making it much easier to implement #2595.)

There are a few implications to this approach for profile authors. A condition is defined in almost the same way, but it must specify whether it is being added to Font (if it is asking a question about an individual testable), CheckRunContext (if it is asking a question about the test run as a whole, or needs to work with the collection of files being tested), etc., and it must take a single parameter, which is the testable object itself. Many of the simpler "standard" conditions are simple cached properties on the Font class.

Some things which were not really conditions but actually utility functions have been reworked as utility functions.

[simoncozens]

@felipesanches I think this is good to go!

[felipesanches]

Great, thanks!

[felipesanches]

I like that checks are now first-class. Similarly to what you've done to code-testing (not requiring an explicit profile name, except when dealing with overriden checks), we should be also able to run a single check from the command-line without specifying a profile.

Also, I think the codebase now is in better shape for integration with font-editors, because it is simpler to invoke a check via simple python imports and method calls. (#4128 (comment))

[simoncozens]

Yeah, there are a few more enhancements we can do in the future but this puts us in a good shape to do them. And yes, totally agree that working with font editors should be much easier now.