Implement Verifiable-Credential-compliant query/txn signature mechanism

Description

v2 Fluree used http-sigs to allow secp256k1 signatures of queries/transactions that allowed for query/transaction processing to resolve queries/transactions as having been provably issued by a particular cryptographic identity. That identity was then used as context for data policy evaluation (i.e. user x issued this query -> this query targets "achievement" data -> a policy on "achievement" data only allows query access if the achievement was issued via "achievement/recipient" to a particular identity -> is user x === the "achievement/recipient" of the queried data -> only return achievements that pass this logic)
v3 Fluree will use Verifiable Credentials to wrap a query in the same cryptographic proof and allow the same behavior
The credentialSubject would be the actual query or transaction itself
Other VC attributes such as issuer and proof would enable the work of validating that the issuer of the query/txn had in fact signed the message and that the message hadn't been tampered with

Queries or transactions can be issued such that the message of the query or transaction is in the shape of a Verifiable Credential
This should be done in such a way that any library that assists with producing W3C spec-compliant verifiable credentials can be used to issue Fluree-compliant queries/transactions
The identity resolved from the VC would be used in policy enforcement for the query/transaction
This ticket does NOT describe additional work to allow a VC to represent a kind of 3rd-party attribution (e.g. attribution service X qualifies that identity Y has attributes A, B, and C that are relevant to policy enforcement). Instead, this allows Identity X to sign their own query/txn, that is, it allows what was effectively possible in v2 Fluree when using http-sigs to prove a query/transaction hasn't been tampered with and to prove that it was signed by a particular cryptographic keypair