Listing differences to the TD specification

Here are some things that the TD specification is requiring but node-wot is not doing:

## Interacting with a Thing on the Consumer side
1. Understanding the `securityDefinitions`: Currently, node-wot uses the credentials provided by the user for a Thing with a certain id and does not look at all into the TD what mechanisms are needed.
2. Not supporting a TD with multiple security schemes: Related to the issue above, if a Thing defines 2 security mechanisms in the `securityDefinitions` object and uses one in some interactions and the other mechanism in other interactions, node-wot cannot do that.
3. Requiring id of a Thing to use security mechanisms: TDs do not necessarily have an `id` field but for the security mechanism of node-wot to work, it has to be there.
4. Handling `readOnly` and `writeOnly` in a granular way: A property that is an object, can have parts/keys that are `readOnly` and others that are `writeOnly`. Given that this property would have `readproperty` and `writeproperty` values in the `op`, it would be tricky to decide whether an error should be thrown before sending the request or let the Thing decide for itself.
5. Parsing the `@context` field. Currently, different protocol vocabularies are hard coded. See related issue: https://github.com/eclipse/thingweb.node-wot/issues/80
6. Not having support for all security schemes in all protocols: This is super difficult to achieve anyways but the following are not possible in HTTP: PSK, ApiKey, Digest
7. ExpectedResponse: Not sure if [this term](https://w3c.github.io/wot-thing-description/#expectedresponse) is parsed in any way. Not sure if it needs to be parsed
8. For HTTP Basic Auth (and possibly other schemes), the values in `in` and `proxy` are not handled. Even if we pass the credentials via a config, we should be able to say `"in":"cookie"`.

## Exposing a Thing
1. Validating inputs: This is not a must but the TD specs says that the values of an interactions should respect the data schema. In node-wot, this responsibility is left to the developer.
2. Handling `subscription` and `cancellation` objects in an event or simply producing a TD that has those objects.
3. Handling `readOnly` and `writeOnly` in a granular way: A property that is an object, can have parts/keys that are `readOnly` and others that are `writeOnly`. It is not possible to expose a Thing that automatically returns "method not allowed" when parts of the object are sent when they are not allowed.
4. Not having support for all security schemes in all protocols: This is super difficult to achieve anyways but the following are not possible in HTTP: PSK, ApiKey, Digest
5. For HTTP Basic Auth (and possibly other schemes), the values in `in` and `proxy` are not modifiable. Even if we pass the credentials via a config, we should be able to say `"in":"cookie"`.
6. multiLang objects are not in the exposed TD: Content negotiation does happen but in the end, `descriptions` and `titles` are not in the produced TD.
7. No check is being done for the following assertion of the TD spec " All MultiLanguage object within a TD document SHOULD contain the same set of language members. ": So if I have en and de in `titles`, and en and it in `descriptions`, there is no error thrown. Playground has check function for this: https://github.com/thingweb/thingweb-playground/blob/1c158f698bde9b21129b419b157959680068fa41/playground-core/shared.js#L369

---

If there are other gaps between the TD and node-wot, please write them in the comments below and I will edit this comment to add them accordingly.