[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/).

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": {
  "textile": "*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.

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).

Remarks
------------

* This specification also touches other endpoints that feature textile + html attributes to establish a **consistent** naming scheme; this might break existing implementations but should be fixed before it becomes even harder to fix
Having to specify which endpoints are supported as a context are probably one of the drawbacks of such a centralized resource compared to each type having it's own textile resource.