PERMISSION: Allow only `Append` to recipient's shared resource list

As per the discussion here https://github.com/anusii/solidpod/issues/182
We could implement a workaround by limiting the public agents to only Append access to recipient's shared resource list (Append access allows POST and PATCH requests to add information, as per description here).

In this case, we may need the following (likely needs to create individual issues for each of them):

• Update shared/.acl to remove the Read, Write access by public agents
• Create a resource list file in shared/, for example, shared_resources.ttl and its ACL file shared_resources.ttl.acl
• Grant Append access to public agents in shared_resources.ttl.acl
• When granting permission to a recipient, append a record in the recipient's shared_resources.ttl with
  • unique resource ID and URI of shared resource
  • access permission granted (perhaps using a grant predicate here)
  • if the shared resource is encrypted, the individual key (encrypted using recipient's public key) as well
• When revoking permission from a recipient, append a record in the recipient's shared_resources.ttl with
  • unique resource ID and URI of shared resource
  • access permission revoked (perhaps using a revoke predicate here)
• Optionally, we could update the shared_resources.list by merging grant and revoke records periodically.

It seems the first three items could be done during POD initialisation, therefore, the initialisation code may need to be updated appropriately.

Questions up to discussion:

• As public agents won't be able to read the shared_resources.ttl, is it still necessary to encrypt the resource URI and access permissions?
• Now that we may have both grant and revoke records in file shared_resources.ttl, the current unique ID will no longer be unique (i.e. the same for the grant and revoke records), therefore, a workaround for this will be needed.

Start by reading the discussion in issue 182 and the linked Web Access Control specification, then inspect POD initialisation and the existing shared/.acl. The proposed work covers shared_resources.ttl and its ACL, append-only public-agent access, and grant/revoke records; completion also requires resolving the encryption and identifier questions.