Add services_cap_add and services_cap_drop config options

What does this MR do?

feat(config): add services_cap_add and services_cap_drop options

Introduce Linux capability management for gitlab-runner service containers, enabling fine-grained privilege control via services_cap_add and services_cap_drop configuration fields in [runners.docker].

Why was this MR needed?

The existing cap_add / cap_drop options in [runners.docker] are only applied to the build container. Service containers (services:) always start with Docker's default capability set, so use cases like running a VPN/network service (NET_ADMIN), or hardening services by dropping all capabilities, were impossible without privileged = true.

This implements the capability part of long-standing feature request #4748, where --docker-cap-add was shown to populate CapAdd on the build container but leave it null on service containers.

Separate services_cap_add / services_cap_drop fields (rather than reusing cap_add / cap_drop) preserve backwards compatibility: existing configurations keep their current behaviour, and capabilities for services are opt-in.

What's the best way to test this MR?

Unit tests

go test ./executors/docker/ -run TestDockerServicesCapAddCapDropSetting -count=1

The test asserts that createHostConfigForService copies services_cap_add / services_cap_drop into the service container's HostConfig.CapAdd / HostConfig.CapDrop.

Manual verification

1. Build the runner and register it with the docker executor, adding to config.toml:

   [runners.docker]
     services_cap_add = ["NET_ADMIN"]
     services_cap_drop = ["ALL"]

2. Run a job that uses a service:

   test-caps:
     services: ["alpine:latest"]
     script: ["sleep 60"]

3. While the job runs, inspect the service container:

   docker inspect <service-container> --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}'

   It should print [NET_ADMIN] [ALL]. Alternatively, exec into the service and check grep Cap /proc/1/status or capsh --print.

4. Regression check: inspect the build container and confirm its capabilities are unchanged (still governed only by cap_add / cap_drop).

What are the relevant issue numbers?

#4748