Add validator support to condition registration and FlagStateForm

[willbarton]

Closes #59. Flag state values were not previously validated in the FlagStateForm, resulting in potential exceptions being raised on flag state checks.

Implementation is loosely based on the code suggested by @Weltraum.

This change supports adding a validator callable when registering a condition. This validator is used by the FlagStateForm to ensure that values entered for conditions are valid for that condition, and to provide feedback if not.

To support that functionality, this change also refactors the conditions code, breaking the registry and the built-in conditions into their own modules, and adding a new module for validators. The API remains the same.

[chosak]

Unfortunately, this implementation causes an error any time the Django admin is used to edit any condition with a required parameter like request (for example). Unfortunately you can't just ignore RequiredForCondition errors, too, because then there's no guarantee that you'll actually execute the logic you want to test.

I'm not sure there's a simple way to validate values in a generic way, as opposed to on a condition-by-condition case.

As a side note, I noticed when testing this using Wagtail that wagtail-flags seem to have its own copy of FlagStateForm (only slightly different), which means this PR doesn't change how things work in Wagtail. Couldn't / shouldn't wagtail-flags use the form from django-flags?

[willbarton]

@chosak Yeah, I see that now.

I'll use this opportunity to add general validation for conditions, I think, something we should have anyway.

[chosak]

Just throwing out an alternate design:

class  MyCondition:
    def __call__(value, **kwargs):
        # check condition

    def validate(value):
        pass

Allow conditions to be optionally defined as callable objects with an optional validate method. This way, the conditions encapsulate their own validation, and you don't need to maintain a separate list of validators.

[willbarton]

@chosak I thought about that, but I think I'd prefer to be able to reuse Django's validators as much as possible — and when not the actual validators, the same approach to validators. That, to me, requires them to be decoupled from the conditions.

It's possible we could support both means through introspection when a condition is registered... but that seems to more complexity without a lot of gain.

[willbarton]

@chosak It turns out, it's pretty easy to support that behavior, as well as the separate condition/validators by storing separate validators as validate attributes on condition callables. Then we can assume that condition_fn.validate always exists if we get the callable out of the condition registry. I've done that in b706418.

[cwdavies]

I have a minor suggestion that could be done in this PR, but it is not something that has to be done.
When I ran git log and tox I was pleasantly surprised to see that Django 3.0 is supported.
My change would be to remove support for Django 1.11 as cfgov-refresh is now on Django 2.2.
The file tox.ini could be updated to remove py36-dj111 and py38-dj30.

[willbarton]

@cwdavies yes, that was in #58. I'd like to keep Django 1.11 around a little while longer.