Ambiguity between readOnly/writeOnly for ExposedThings

In spirit of documenting how node-wot handles the open issue [Undefined behavior for writeOnly and readOnly](https://github.com/w3c/wot-thing-description/issues/1005), I created the following table.

The table summarizes how node-wot handles `readOnly`/`writeOnly` values in a property affordance when exposing things:

| ExposedThing 'op' (for properties) | readOnly: true | readOnly: false |
|:---------------------:|:----------------:|:---------------------------------:|
| **writeOnly: true** | ['readproperty'] | ['writeproperty'] |
| **writeOnly: false** | ['readproperty'] | ['readproperty', 'writeproperty'] |

NOTE: false is the default value used when ommiting `readOnly`/`writeOnly` (see [here](https://w3c.github.io/wot-thing-description/#sec-default-values))

Putting both `readOnly` and `writeOnly` into a truth table, the case where this is ambiguous is only really when both values are present and true, for example:

```json
{
"temperature": {
"title": "Temperature",
"type": "number",
"readOnly": true,
"writeOnly": true
}
}
```

In this case, 'node-wot' will expose the thing and create the following form for it:

```json
{
"temperature": {
"title": "Temperature",
"type": "number",
"readOnly": true,
"writeOnly": true,
"forms": [
{
"contentType": "application/json",
"href": "/properties/temperature",
"htv:methodName": "GET",
"op": [
"readproperty"
]
}
]
}
}
```

Thinking about this, I guess it does make sense that node-wot takes (wether intentionally or not) the secure-first approach (`readOnly` overwrites `writeOnly` when both are true).

Anyways, I just wanted to post this as reference for others.