API Data and Framework Versioning.

[matajoh]

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.

"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:

"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:

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

and the value returned by an older policy is:

{
    "allowed": true,
}

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

{
    "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:

"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.

[matajoh]

@anmaxvl @helsaawy