* API Data and Framework Versioning.

This change adds several features that are necessary to provide stable backwards
compatibility.

The first deals with how API defaults are specified.
Previously, API default behavior was given in terms of allow/deny, i.e.

``` rego
"create_container": {"introducedVersion": "0.1.0",
                     "allowedByDefault": false}
```

This does not reflect how the API has evolved, in particular the fact that GCS
expects the API to return objects and not a single boolean value. Thus, the
defaults have been updated to be default object values:

``` rego
"create_container": {"introducedVersion": "0.1.0",
                     "default_results": {"allowed": false,
                                         "env_list": null,
                                         "allow_stdio_access": true}},
```

The resulting default object is then combined with the value returned by the
(older) policy using an object union operation. For example, if the
default is:

``` json
{
    "allowed": false,
    "env_list": null,
    "allow_stdio_access": true
}
```

and the value returned by an older policy is:

``` json
{
    "allowed": true,
}
```

then then the fields of the policy result overwrite the fields of the default
to create the final result:

``` json
{
    "allowed": true,
    "env_list": null,
    "allow_stdio_access": true
}
```

As the API stabilizes, it will increasingly be the case that the Framework will
change independently of the API and will need its own SVN. The second major
change this PR incorporates is to add a Framework SVN to fragments and policies
which use the provided framework. This allows us to provide Framework-specific
backwards compatibility behavior. In particular, this allows us to specify
policy object versioning via the new `framework_objects.json` file. For example,
the format of the external process object is defined as:

``` json
"external_process": {
    "command": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "env_rules": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "working_dir": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "allow_stdio_access": {
        "introduced_version": "0.1.0",
        "default_value": null
    }
},
```

As new elements are added to framework policy objects, reasonable defaults can
be provided here. This has repercussions on policies in a few cases:

1. **`framework_svn` is missing.** If the policy or fragment does not define a
   Framework SVN, then the framework must thrown an error for any rule which
   uses the object defaults, as the behavior is undefined.
2. **`framework_svn` is ahead of the executing Framework SVN**. Similarly, if
   a policy or fragment specifies an SVN which is greater than that of the
   executing Framework, they are indicating that they expect a different set of
   constraints to be executing and thus we must thrown an error when rules
   that uses object defaults are executed.

Implementing and testing these changes required some minor alterations and
refactoring to the `regopolicyinterpreter`, in particular a method to make
raw Rego queries to facilitate testing the default application process for
candidate policy objects.

Signed-off-by: Matthew A Johnson <[email protected]>