Rework how Coordinates are represented (in memory and JSON)

Since #916, (almost) each coordinate is wrapped in an `IncludedBuildCoordinates`. This makes the _Coordinates_ type hierarchy more complex and it now is a mix between composition and inheritance. I think it is worth to take a fresh look and possibly refactor the type hierarch of _Coordinates_ and its subtypes. The subtyping has caused other sneaky issues in the past – e.g. when comparing Coordinates (#822).

Possible ways to go:
- No subtyping at all - instead have one `Coordinates` type with multiple (but optional) "IDs/represenations"
- Keep hierarchy but clean it up, move all code that is now doing a type check into methods on the `Coordinates` classes

Gains of this:
- General more stable code with less edge cases to consider (e.g. doing different things for different `Coordinates` subtypes in multiple places.)
- Possibly reduced memory footprint by less wrapping of many coordinates objects in many places (for large builds)
- Reduced disc usage by more compact representations in JSON
- Easier to read (intermediate) JSON result files
- Cleaner API for post processor tasks

Start by tracing the Coordinates type hierarchy and IncludedBuildCoordinates, then review the context from #916 and the comparison issue in #822. Determine which representation and subtype behavior should be retained, including the in-memory, JSON, and post-processor impacts described here. Done means the refactoring direction is decided and the affected representations and APIs are consistently updated.

Written by the indexing model from the issue text.