## Relevant issue(s)
Resolves #2762

## Description
This PR introduces the ability to make use of the `relation`s defined
within a policy to create relationships between an actor and a document
within a collection. For users sake, I have made the clients (http, and
cli) not consume the `policyID` and `resource` name but instead a
`docID` and `collection name`, since the collection will have the policy
and resource information available we can fetch that and make lives
easier for the users.

This PR also makes use of the `manages` feature we have had in our
policy. The manages essentially defines who can make the relationship
manipulation requests.

There are a lot of tests in this PR due to a lot of edge cases I wanted
to have tested specific to `manger`, and ensuring `write` and `read`
permissions don't leak (i.e. are accidently granted).

## CLI Demo
The following lets the target actor be able to now read the private
document:

```bash
defradb client acp relationship add \
--collection Users \
--docID bae-ff3ceb1c-b5c0-5e86-a024-dd1b16a4261c \
--relation reader \
--actor did:key:z7r8os2G88XXBNBTLj3kFR5rzUJ4VAesbX7PgsA68ak9B5RYcXF5EZEmjRzzinZndPSSwujXb4XKHG6vmKEFG6ZfsfcQn \
--identity e3b722906ee4e56368f581cd8b18ab0f48af1ea53e635e3f7b8acd076676f6ac
```

Result:
```json
{
  "ExistedAlready": false // <-------------- Indicates a new relationship was formed
}
```


### Future (out-of-scope of this PR):
- Most of write tests will split into `delete` and `update` in #2905 
- Ability to revoke or delete relation coming in #2906 
- Decide on the `can't write if no read permission` in #2992 
- Move acp logic to a shared repo:
#2980


## How has this been tested?
- Integration tests

Specify the platform(s) on which this was tested:
- Manjaro WSL2

## Relevant issue(s)
Resolves sourcenetwork#2762

## Description
This PR introduces the ability to make use of the `relation`s defined
within a policy to create relationships between an actor and a document
within a collection. For users sake, I have made the clients (http, and
cli) not consume the `policyID` and `resource` name but instead a
`docID` and `collection name`, since the collection will have the policy
and resource information available we can fetch that and make lives
easier for the users.

This PR also makes use of the `manages` feature we have had in our
policy. The manages essentially defines who can make the relationship
manipulation requests.

There are a lot of tests in this PR due to a lot of edge cases I wanted
to have tested specific to `manger`, and ensuring `write` and `read`
permissions don't leak (i.e. are accidently granted).

## CLI Demo
The following lets the target actor be able to now read the private
document:

```bash
defradb client acp relationship add \
--collection Users \
--docID bae-ff3ceb1c-b5c0-5e86-a024-dd1b16a4261c \
--relation reader \
--actor did:key:z7r8os2G88XXBNBTLj3kFR5rzUJ4VAesbX7PgsA68ak9B5RYcXF5EZEmjRzzinZndPSSwujXb4XKHG6vmKEFG6ZfsfcQn \
--identity e3b722906ee4e56368f581cd8b18ab0f48af1ea53e635e3f7b8acd076676f6ac
```

Result:
```json
{
  "ExistedAlready": false // <-------------- Indicates a new relationship was formed
}
```


### Future (out-of-scope of this PR):
- Most of write tests will split into `delete` and `update` in sourcenetwork#2905 
- Ability to revoke or delete relation coming in sourcenetwork#2906 
- Decide on the `can't write if no read permission` in sourcenetwork#2992 
- Move acp logic to a shared repo:
sourcenetwork#2980


## How has this been tested?
- Integration tests

Specify the platform(s) on which this was tested:
- Manjaro WSL2