Better separation between pure batch job metadata and batch job *result* metadata

This was slightly bugging me for some time, but resurfaced with #184:
BatchJobMetadata was initially intended as a container for batch job metadata, relatively closely following the spec of openEO resource GET /jobs/{job_id}. So it was meant for metadata purely about the batch job itself, nothing about batch job results.

Over time various result related fields were added to BatchJobMetadata due to lack of a dedicted batch job result metadata container at that time. Now it makes the object sometimes confusing to use (initialize/update/export/...). I also suspect there are some fields related to non-standard Geopyspark features.

I recently added BatchJobResultMetadata for some new result related fields I wanted to handle and keep out of BatchJobMetadata
But we might also want to migrate some existing fields from BatchJobMetadata to BatchJobResultMetadata

Start by locating the BatchJobMetadata and BatchJobResultMetadata definitions and reviewing how they are initialized, updated, and exported. Identify existing result-related fields and determine which belong in BatchJobResultMetadata; done means the separation and migration scope are clearly defined and consistently applied.