version 7 - Design

Starting a thread here to put notes on a version 7 design.
Version 7 is an opportunity to make a number of changes that have been suggested in issues filed here that would make the JSON rules engine more extensible at the cost of breaking backwards compatibility with the current 6.x versions.

### Extensibility vs. Structure
With version 7 we want to consider the tradeoff between extensibility and having a known structure. For instance introducing the ability to add custom `Condition` classes or custom `Rule` subclasses allows for the system to be highly extensible but makes it much harder to reason about the input and output of the rules engine without knowing about all these extensions.

Ultimately we need to draw this line somewhere and my initial inclination is to draw it in favor of more extensibility in order to allow the broadest possible use of the rules engine.

### Concepts
Starting from a clean stale the following basic concepts will be part of the rules engine

**Facts**
Facts are things that are known by the rules engine during execution.

**Almanac**
The Almanac is the system for storing and looking up `Facts`.

**Conditions**
Conditions are executable, contain a priority, and return a result containing a boolean value. Generally there are 2 types of conditions, comparison conditions which check the value of a fact against another value, and composite conditions like `all`, `any`, and `not` which use 1 or more nested conditions to produce a result. By being fully extensible it's possible to introduce other types of conditions.

**Rules**
Rules are also executable and contain a priority. They generally are comprised of a set of conditions which are executed. Rules produce events as a result of execution.

**Engine**
The engine provides the mechanism to evaluate rules, and conditions. It includes mechanisms to resolve the values of facts or other special objects. Changing the engine can significantly change the behavior of the system.