Outdated `Project#has_ci?` and `MergeRequest#has_ci?`

Problem

Project#has_ci? and MergeRequest#has_ci? are outdated and have a couple of problems.

• Project#has_ci? doesn't take ci_config_path into account. For example, when a user changed the default path of .gitlab-ci.yml, this function returns a wrong result.
• Project#has_ci? doesn't take project.ci_service into account. For example, when a user setup external CI service as an integration, this function returns a wrong result.
• Project#has_ci? fetches full-sized blob for checking the file existence. This is not ideal from performance perspective. We can use Gitlab::Git::Blob.find instead with specifying limit: to zero. This way, Rails can ask Gitaly not to return the full-sized blob but just checking file existence.
• MergeRequest#has_ci? should be delegated to Project.has_ci?, as the current logic doesn't cover the whole cases. Simply, "Having no pipelines" does NOT mean "The project has not setup CI for MRs". Today, users can setup a complex pipeline/job rules (or only/except) and cannot conclude has_ci? by just checking the pipeline existence. Also, it contains a race condition that pipelines might not exist regardless of the .gitlab-ci.yml existence because of the nature of asynchronous pipeline creation.

Proposal

• Fix Project#has_ci? to respect the other cases.
• Avoid repository.gitlab_ci_yml and uses Gitlab::Git::Blob.find instead.
• MergeReqest#has_ci? should be delegated to source_project#has_ci?