Kubernetes executor should only used SharedBuildsDir behaviour when it is required

What does this MR do?

This changes the default builds dir path back to what it was previously, enabling SharedBuildsDir behavior only when it is required. I.e. by default a runner will use a static /builds/<path/to/project> path within the build container, enabling SharedBuildsDir behavior only when a volume which is NOT an empty_dir for /builds has been specified. For example...

This will use the default behavior as it is an empty dir and thus the job is isolated:

  builds_dir = "/builds"
  [runners.kubernetes]
    [[runners.kubernetes.volumes.empty_dir]]
      name = "repo"
      mount_path = "/builds"
      medium = "Memory"

This will use the SharedBuildsDir behavior which is required to support multiple concurrent jobs:

  builds_dir = "/builds"
  [runners.kubernetes]
    [[runners.kubernetes.volumes.host_path]]
      name = "repo"
      mount_path = "/builds"
      host_path = "/mnt/builds

Docker runners currently do a similar check, only setting SharedBuildsDir to true when a host volume is used (see here) and so this change will shift the Kubernetes executor behavior into a similar vein, providing flexibility where needed while still supporting use-cases where the value of $CI_PROJECT_DIR must remain identical between jobs.

Why was this MR needed?

Support for overriding the builds dir was added in !2862 (merged) and as a side-effect the default builds dir path changed breaking CI jobs that fail to use $CI_PROJECT_DIR as well as jobs which simply cannot run with a $CI_PROJECT_DIR value that differs between jobs.

Terraform jobs which pass plan artifacts forward into an apply job is an example of where a static builds dir path is required. Hashicorp explicitly documents that when passing artifacts, the absolute paths must remain the same between plan and apply operations to avoid potential issues. When using a using a plugin cache the builds immediately break when job A runs with a concurrent ID of 1 and job B (which accepts artifacts from Job A) runs with a concurrent ID of 2 as there will be symlinks in the artifact pointing at files that do not exist in Job B.

What's the best way to test this MR?

Unit tests were added to test the expected behavior, asserting the correct values for SharedBuildsDir. Manually testing this MR will require deploying multiple kubernetes runners with the following scenarios:

a) Default builds dir (i.e not user specified)

b) User specified empty_dir

c) User specified host_path, pvc, etc (anything other than an empty_dir)

What are the relevant issue numbers?

#27918 #27995 #28023 !2862 (comment 641145977)