Create, implement and document a policy for projects on CI

Currently there is no policy regulating which projects are accepted on Bazel CI. Users simply file an issue, and we periodically work through the backlog.

Going forward this has to change, especially given that our computing resources are limited.
Action items:

1. Develop and publish guidelines on which projects are eligible to run on CI.
2. Draft a codelab that teaches non-eligible projects how to set up an alternative (e.g. based on GitHub actions).
3. Create and publish guidelines that the Bazel team expects pipeline owners to adhere to. For example, we might disable pipeline that have been inactive for a long time.
4. Streamline the onboarding process by documenting additional required steps. For example, it would be easier for us if users already included an email address in the initial onboarding request so that we can send them webhook instructions. Moreover, we should mention that automatic commit status updates in GitHub require the repository owner to connect their GitHub account to the Buildkite app, or that @bazel-io must be added as a collaborator.
5. Draft a policy that describes which projects qualify as part of the downstream pipeline, and how they can be added.

No files or tests are named. Start by breaking the five action items into separate policy and documentation deliverables; done means published eligibility, onboarding, pipeline-owner, downstream-pipeline, and alternative-CI guidance, including the proposed codelab.

Written by the indexing model from the issue text.