Richer status for items processing on the server

## Is your feature request related to a problem? Please describe.
Currently, items that are processing on the server can only be identified via their status `425` response, so clients can only show a generic message (i.e. "Processing on the server…"), but can't offer any real feedback or insight as to what's happening to the item - or its status in processing.

Scenarios where communicating status would be useful:
- workflows that require a human to f.ex. approve a file. Possible status:
- "Waiting for approval"
- "In Review"
- workflows processing a file, f.ex. virus scanners or compressors. Possible status:
- "Compressing to MP4…" (23%)
- "Scanning for viruses…" (17%)
- a file is locked
- "Locked by [user]"

## Describe the solution you'd like
The processing status of an item could be communicated by three new tags in the WebDAV response:
- `oc:processing-message`: containing the message from the workflow if available
- `oc:processing-progress`: containing the progress of the workflow if available (range 0-100)
- `oc:status`: a string indicating the current status of the file, f.ex. `normal` (status 200), `processing` (status 425), `locked`, decoupling this from HTTP status codes and allow finer grained status levels (f.ex. in a "backwards-compatible" reverse domain style like `processing.queued`) if they are needed

A change of status would ideally trigger a `CTag` update of the processed item, but in absence of support for `CTag`s, it should trigger an `ETag` update on the parent folder, so clients can detect and retrieve the updated information.

If many files are processing and changing their status at the same time, frequent status updates could create considerable load on the server through clients polling for changes. This issue could be greatly reduced by rate-limiting ETag updates triggered by `oc:processing-progress` (and possibly also `oc:processing-message`) updates to f.ex. one per minute – on a global level. Picking a rate limit should focus to striking a balance between the interest of the user on up-to-date status information, how often status information should update to provide a real benefit - and the goal of keeping the load on the server as low as possible.

Changes in `oc:status`should, however, always trigger a parent folder `ETag` change immediately as it can also mean a change in what users can do with an item.