[API] Specify endpoints for change of WP-Description (incl. Preview)

This PR specifies:
* [#16973](https://community.openproject.org/work_packages/16973)
* [#16983](https://community.openproject.org/work_packages/16983)

Discussion points
----------------------

### Preview

My PR contains two possible realizations for a preview-endpoint. ~~The first one in commit https://github.com/opf/openproject/commit/c22bad164ead9fcbf590883ffbbfe9777842650b, where the client issues a request using a **JSON** object. This solution is quite close to [the way GitHub does it](https://developer.github.com/v3/markdown/).~~ (I think we agreed that this is not the way to go)

As we want to use this endpoint in a HAL-API I see the problem that providing a **valid context** is not very *explorable* when it is embedded in the request-body.

I'd rather like to be able to **link** from a work-package to the endpoint directly using the work package as context. This is easier if the context was provided as query-parameter. Therefore commit https://github.com/opf/openproject/commit/7c4efe3918d2ddc864af27694e91ffc29a6b3cf4 expects the context as query-parameter. This has the additional benefit that the request body is now very clean in that it only contains the textile that should be rendered as **plain text** (without the need for escaping).

A possible extension for the context-as-query version is to provide local rendering resources, like `api/v3/work_packages/42/render/textile` instead of `api/v3/render/textile?context=api/v3/work_packages/42`, however this extension is entirely optional and I would rather not specify that now.

### Textilizable attributes

There was once discussion whether textile-attributes (like the description) should be represented in a special way to better group their various representations:

````JSON
"description": {
  "format": "textile",
  "raw": "*Foo*",
  "html": "<strong>Foo</strong>"
}
````

This would affect a number of properties in different resources. The benefit is that it becomes clear that the html description is just another representation of the textile description, but that both basically belong to the same attribute. It is also more extensible with regards to future support of more formatting languages.

~~However having a JSON-property for something as basic as the description of a WP might also be considered overkill and would make it even harder to **specify** read-write-capabilities (html vs. textile) and it would also make the implementation of a form endpoint harder.~~
~~I therefore decided to [KISS](http://en.wikipedia.org/wiki/KISS_principle).~~

After @myabc motivated me to do the right thing I changed the specification to follow this approach.
I believe that in the current state of specification this should not contradict the implementation of a form endpoint and specification of read-write should be quite clear.

Remarks
------------

* This specification also touches other endpoints that feature textile + html attributes to establish a **consistent** representation of formatable text; this might break existing clients and needs additional server-side changes, but I think it should be fixed before it becomes even harder to do