This change introduces the core support for condition rules. These are a
way to allow applications to give users a degree of flexibility for
choosing when certain actions should take place. Users can define one or
more "conditions," which consist of a "condition choice" (a property or
an object, generally, that the condition is matched upon), an "operator"
(which applies to a choice -- something like "is", "starts with",
"greater than", etc.), and a value (depending on the type of choice and
operator). Along with these, they can decide whether all conditions must
match, or any of them.

For example, if an application wants to post notifications to a chat
service, it could allow the user to customize under what conditions a
message would be sent, making it easy to have a range of per-channel
configurations.

Conditions can be serialized to a JSON-compatible form (useful for
storage in JSONFields or elsewhere), and deserialized from them as well.
This makes them usable just about anywhere, including in API requests.

Consumers would create a set of condition choices they want to expose
for some part of their application. Each choice has an ID (unique within
that batch of choices), a human-readable name, a list of one or more
operators, and an optional default value field (which handles
representing input fields on a web UI and handling
serialization/deserialization).

Operators, similarly, have an ID and a name, and can optionally override
the value field (allowing, for instance, some operators for a date-based
choice to show calendar entries or numeric text fields, whichever is
more appropriate). It also contains the logic for matching a stored
condition value with the lookup value from the caller.

Both the list of choices and list of operators are registries, which
allows other code (such as extensions) to add additional
choices/operators to any existing list. Through this, authors could add
even more flexibility for conditions beyond what the application author
intended, helping to match on specific types of metadata or state in the
database or anything else the author wants.

This is just the beginning of this support. Upcoming changes will add
standard sets of choices, operators, and values, and will introduce
standard UI for configuration conditions.

Unit tests pass.
Tested this along with the upcoming changes, adding working condition

support in an extension.