Add a "has result" flag or link

[m-mohr]

Right now the "finished" (and sometimes "error") state says that there might be results. Nevertheless, this is ambiguous. If you update the process graph, some implementations may revert back to "created" and then it's unclear whether results are still available or not.
It would probably be a good idea to decouple the "status" and the "has result" indicators. We can keep the status as is and add either a flag "has_result" and/or a link to the results in the metadata regardless of the status.

[soxofaan]

Alternative proposal: Reconsider the fact that batch jobs can be updated.
This mutability causes quite some complications around how to reason about and handle batch job status, state, results, etc. (E.g. also see #442, #436, #384 )
I think creating a new batch job is so cheap/easy in all clients and on all back-ends, that supporting batch job updates is just not worth having to deal with all the complications it brings.

I understand that this would be a breaking API change, but technically with the current API, a back-end could is allowed to not support PATCH /jobs/{job_id} and not having to worry about batch job updates, right?

[m-mohr]

I think it's okay and pretty useful to update title and description (i.e. metadata). But we may want to disallow updating the process graph. That would simplify things in most clients except the Web Editor, I guess. And simplify the back-end implementation for sure.

In the current API it is allowed to not support PATCH /jobs/:id, indeed.

The flag would still be useful as the ambiguity regarding the error state is still relevant.

[m-mohr]

GET /jobs and GET /jobs/{job_id}: Added a links property that can for example link to results and logs.