Use per-build token to acts as an user triggering a build

What does this MR do and why is needed?

This tries to solve a long outstanding problem https://gitlab.com/gitlab-org/gitlab-ce/issues/18107 (checking out and accessing dependent projects).

The Merge Request introduces a build token, token that allows to access a source code / LFS objects / container images with a permission of a user triggering a build. The access is read-only for repository / LFS, but read-write for container images of a project on which a build is triggered.

This appears to have less edge-cases then any other already discussed solution: https://gitlab.com/gitlab-org/gitlab-ce/issues/18994 (this issue describes this approach), https://gitlab.com/gitlab-org/gitlab-ce/issues/18993 (Internal readable by CI tokens). It works for users that are external, and internal. It works for public, internal and private projects. Thus allowing to fetch submodules from all projects to which user has access. This also makes it possible to have a full accountability of actions.

This also increases the security of checking out sources, since we generate a token for each build. The token is valid only when the build is running.

Are there points in the code the reviewer needs to double check?

The security implications of the changes.

What are the relevant issue numbers?

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/18090 Fixes #18994 (closed)

Does this MR meet the acceptance criteria?

• CHANGELOG entry added
• Documentation created/updated I will be creating a user documentation and impact of these changes to properly annouce that with the release
• API support added
• Tests
  • Added for this feature/bug
  • All builds are passing
• Conform by the style guides
• Branch has no merge conflicts with master (if you do - rebase it please)
• Squashed related commits together