Update Link (and SecureLink) in specification based on 563 model changes.

Specifications for DPP and DCC are updated where they use Link or SecureLink, based on the model change of !563 (merged) which itself was based on the issue #408 (closed).

Note, that as mentioned in #408 (closed) (albeit only in passing), this documents the removal of the encryptionMethod property. Based on the comment in #408 (closed) I think it may have been removed only because I couldn't see how it could be used sensibly (though that could be my lack of understanding here). At the time, I documented my thoughts around this in #469 (well, earlier on GH but imported there), which I'd summarise as we shouldn't be (encouraging) publishing of encrypted data that can be accessed without authn/authz as it can only be decrypted with the key(s) set when the data is published - instead, we should be linking to data that requires authz (also outlined in the decentralised access control doc), and a 401 Unauthorized or valid 200 response can always include information about any encryptionMethod required for the returned data in the response headers - so I didn't see why we have encryptionMethod.

But that issue (#469) not been addressed, I guess at this point the options are:

1. That I go back and re-add encryptionMethod to Link as an optional property and then update this MR,
2. If encryptionMethod isn't yet used in Links (different to linksets, I think, but not sure?), then update the decentralised access control to remove its use.

Let me know what you think.

Note also: Roman also brought up a further change that would replace Link altogether with a standard relatedResource property as outlined in #554 which references the Integrity of Related Resources section of the VCDM 2.0 spec. I'd tackle that separately if we decide to do it, but it similarly only has integrity protection, not encryption.