Add "OpenEO-Identifier" header to synchronous processing response

[soxofaan]

For accounting purposes, we want detailed tracking of processing costs. For batch job it's trivial to use the batch job id to associate processing costs. For synchronous requests we use internal "request ids", but that is not exposed in a standard way to the end user.

This PR adds a "OpenEO-Identifier" header to the sync processing response, much like the "create batch job" endpoint

[m-mohr]

I'm not sure about this. Synchronous processing was meant to be somewhat stateless, but providing an identifier here would somewhat imply state. The other thing is that in the API the identifier would have no further purpose right now, so I'm somewhat hesistant to add it to the spec quite yet.

You can still implement it if you want, but I'm not convinced yet that this should be part of the core specification (while I'm currently trying to slim sown the core spec as well). If we'd have broader demand I'd reconsider it.

[soxofaan]

Purely at API surface, synchronous processing is indeed stateless, but in reality on a real back-end you are consuming real resources, which involves accounting or credit spending. You are probably triggering logging/events at the back-end which need some kind of correlation id anyway. And with concepts like export_workspace you could even trigger non-ephemeral storage of your result.

I understand you want to slim down a core spec, but this one would be a simple, optional response header, which just aligns sync and batch jobs.