Define child and parent pipeline in model

What does this MR do?

Related to: #16094 (closed)

In this MR we want to have the backend providing all necessary information to the frontend in order to display Child or Parent labels for same-project pipelines.

1. Define Ci::Pipeline#child? and Ci::Pipeline::parent? methods so that we can display Child or Parent labels on the frontend for a given pipeline. (Frontend MR: !21323 (merged))
2. Expose project in PipelineDetailsEntity so that we can compare the project of downstream/upstream pipelines with the one from the given pipeline and determine (in the frontend) whether the pipeline is child, parent or cross-project downstream/upstream. (Frontend MR: !21332 (merged))

For (2) above I originally tried to have the backend exposing a field child: true/false and parent: true/false in the pipelines/:id.json response, so that the logic would remain in the backend. Unfortunately this would introduce 2 additional queries for each pipeline to display in the Downstream/Upstream column of the pipeline graph: 2 * N + 1 queries which I don't think is acceptable from performance perspective.

Instead I've decided to expose minimal project info in the main pipeline JSON object so that in the frontend we can compare it with the dowstream/upstream project and display the labels by consequence. This is a minimal change on the backend and I believe minimal for frontend too.

The downside of this is that it brings some duplication to the frontend but on the upside we don't perform additional queries.

We could improve this is a specific performance optimization issue for pipeline graphs as there are some N+1 queries we already have today for this request.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team