Expand CI_PROJECT_ID in docker volumes

What does this MR do?

When creating a build, some allowed environments are expanded. Now only CI_PROJECT_ID is allowed. After expanding, we introduce dynamic host path for docker mounts.

Why was this MR needed?

With this feature, we can more safely share the build_dir or cache_dir by adding a project id in host path.

Runner seems to have three methods for volumes

a) host-bound path b) host-based cache volume c) docker cache volume.

All these three ways should have ability of project&concurrent level isolation. In addition in some scenes, b) and c) is not suitable, such as:

• for local disk part management, some in-container path have to binding to different host base paths, so b) is not suitable which always use [runner.docker.cache_dir] as based dir, and c) will consume docker graph storage which sometimes is too small
• admin does not want to create too many docker volumes, so [runner.docker.disable_cache] is always true, which will blocking both b) and c), whilst b) seems should not be disabled.

What's the best way to test this MR?

Create a docker runner, mount the build dir like this:

/path/to/builds/$CI_PROJECT_ID:/builds

Then, in the job view, one can only read/write the content of the same project with current job. In the mean time, the build dir is still shared with different runners/jobs for same projects. On the other side, in the host view, all the build dir will be in the patten:

/path/to/builds/<project-id>/<runner-short-id>/<concurrent-id>/<project-slug>

What are the relevant issue numbers?

Close #27181