Streamline constraints

[patrickkwang]

See #157.

Currently we really have two types of constraints on query-graph nodes/edges. There are the "first-class" constraints like categories, predicates, and ids, and there are the "second-class" constraints. Translator imposes some special rules on the former around their format and value sets and how they should be interpreted (subclassing, etc.). But intuitively they serve the same function as the less-standardized second-class constraints. TRAPI messages would be easier to read, write, and parse, if we used the same format for all constraints. Instead of

{
    "categories": ["biolink:Disease"],
    "constraints": [
        {
            "id": "biolink:highest_FDA_approval_status",
            "operator": "==",
            "value": "regular approval"
        }
    ]
}

We could have

{
    "categories": ["biolink:Disease"],
    "biolink:highest_FDA_approval_status": "regular approval"
}

This makes the (intuitive, I think) assumption that "==" is the default operator. To express more complex constraints like

{
    "constraints": [
        {
            "id": "biolink:p_value",
            "operator": "<",
            "value": 0.05
        }
    ]
}

We can do for example

{
    "biolink:p_value": {"$lt": 0.05}
}

where I've borrowed the constraint construction from MongoDB: https://docs.mongodb.com/manual/tutorial/query-documents/

This implies some limits on the allowed constraint values, perhaps that they are not objects. I don't expect this to be problematic.

To retain backwards compatibility with structures like "categories": [...] in this framework, we'd have to prohibit list values as well. Or we could adopt a more explicit alternative like "category": {"$in": [...]}.