Introduce explicit model for the "circuit definition"

**NOTE**: _This issue is Work In Progress_.

Quoting the [Internet Draft](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03#section-1) (Introduction, second paragraph):

> The validation function for these compound signatures takes as input **the fingerprint of the circuit, called the condition**, **the circuit definition and minimum required logic gates with their inputs, called the fulfillment**, and a message.

```
CircuitDefinition
-----------------
/ \
/ + inputs
/ \
Condition Fulfillment
```

### Problem
Both the `Condtion` and `Fulfillment` are represented by classes, but the **circuit definition** is somewhat implicit, hidden within the `Fulfillment` model/class. This is somewhat problematic or cumbersome for applications to construct `Fulfillment` instances. That is, given a `Condition` instance (URI or binary form). even though one may have all the necessary secret information (inputs), one is lacking the circuit definition (topology), which is "hidden" behind the fingerprint of the `Condition` instance.

### Proposed Solution
In order to address this problem, this issue wishes to introduce an additional class, say `CircuitDefinition`, which would act as the bridge between the `Condition` and `Fulfillment` classes. When composing a `Condition`, one would first instantiate a `CircuitDefinition` object, from which a `Condition` instance could be generated, from which the different encodings can be generated (binary, URI, and JSON). Using the same `CircuitDefinition` instance, one could feed it inputs, such that a `Fulfillment` instance could then be generated.

In this way, applications would have a direct, clear, and clean way to communicate the **circuit definition** that is required by those who are constructing a `Fulfillment` instance.

### Modeling a Crypo-Conditions Circuit Definition in Python
_This is an "open question"._

#### [`networkx`](https://networkx.github.io/)
Since a boolean circuit can be viewed as a directed acyclic graph, one approach could be to use the [Networkx](https://networkx.github.io/) library.

NOTE: The model will need to account for the fact that given inputs will belong to specific Conditions (edges, or vertices, within the graph). This shouldn't be a problem though, as long as the edges/vertices have attributes that identify the Conditions. Since Conditions are uniquely identified via their URI, or binary forms, they can be used as an "indexing" mechanism.

#### [`pyeda`](http://pyeda.readthedocs.io/en/latest/)
_Have yet to look into it._
docs: http://pyeda.readthedocs.io/en/latest/

#### Truth Tables
/cc @trentmc