Add di_vc and di_vp formats

With the move towards the new data integrity vc spec (https://www.w3.org/TR/vc-data-integrity), it is now recommend to use `DataIntegrityProof` proof type.

This means that the actual crypt schema that is used is hidden, and thus the filter becomes a lot less useful.
Therefore I think it might be useful to register a new `di_vc` and `di_vp` claim format which define a new `cryptosuite` property:

```json
{
"^di_vc$|^di_vp$": {
"type": "object",
"additionalProperties": false,
"properties": {
// used for proof.type values (either DataIntegrityProof or custom one)
"proof_type": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
},
// used for cryptosuite property of `DataIntegrityProof`, if `DataIntegrityProof` is include in `proof_type`)
"cryptosuite": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
}
}
}
}
```

An alternative would be to extend the ldp_vc and ldp_vp with an optional `cryptosuite` property that can be used if the `DataIntegrityProof` type is used:

```json
{
"^ldp_vc$|^ldp_vp$|^ldp$": {
"type": "object",
"additionalProperties": false,
"properties": {
"proof_type": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
},
"cryptosuite": {
"type": "array",
"minItems": 1,
"items": { "type": "string" }
}
}
}
}
```

as data integrity is also the new name of the spec, it might be good to register the new `di_vc` either way.