This enables users of hookiedookie to extract most of the information
they need from the payload and pass it through to the workload as
environment variables - thus removing the need of the callers to handle
the payload format themselves.

Example would be to extract the issue id from a gitlab webhook roughly
like this:

   rules:
     and:
       - matches:
           key: "object_kind"
           value: "issue"
       - follow:
           key: "object_attributes"
           op:
             export:
               key: "id"
               name: "GITLAB_ISSUE_ID"
   run:
     - "bash"
     - "-c"
     - "do_something $GITLAB_ISSUE_ID"

The `export:` operation can have a nested operation, in which case it
will return the value of that operation (and optionally export), e.g:

  rules:
    or:
     - export:
         key: "object_kind"
         name: OBJECT_KIND
         when: always
         op:
           equals:
             key: "object_kind"
             value: "issue"
     - equals:
         key: "foo"
         value: "bar"

In this example, OBJECT_KIND is always exported into the environment
variable even if the nested equals fails. But the result of the export
is that of the nested op.

These exports are treated as "side effects" in the code, with
environment variables being the only currently supported side effect.

The parsing of string-based values needs to be special-cased to not end
up with strings like "\"foo\", otherwise the values are serialized back
to JSON mostly as expected.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>