- stage
- query
- multiquery
- history

In order to handle string requests, we need to understand string when discerning whether
we're dealing with an insert or a retract, so there are a couple updates to handle
that (fql.parse/update? and update/insert? and update/retract?).

In each case we unwrap the credential subject before parsing. We only use a limited
subset of the credential spec internally, but the wide world of credentials has a very
large schema and I didn't want to include it in our internal query/transaction schema.

We were just pulling the "issuer" field off of the verified credential, but that part of
the credential is not signed. Now we just use the did key from the proof, which is part
of the cryptographic signature.

Also refactored the `generate` function and stubbed out an assertion that we can use in
the future once our incoming credential subjects are proper json-ld.

If no role is specified, but a did is, look up the roles associated with the identity
and enforce them on the operation.

When staging with a policy-activating opt (:did or :role), you need to be able to
subsequently transact with different policies for different users. This commit makes
that possible by resetting the db to a root db after checking policies.

If you want to interact with the db with a specific policy wrapping, you need to specify
the identity/role with which you are doing so every time.

Since we know the subject ids for the predicates we care about, we don't need to invoke
the whole query pipeline in order to get the results we care about.

Cleaned up a redundant ns require for fql.

Added some test cases to verify that no errors are thrown when there are no roles or
identities.

We were looking up an identity's roles, then looking up those roles iris, only to
translate them back into iris.

This allows us to skip the iri lookups and just keep the sids.

Also, there's a function for (not (not-empty ...)).