Send system_id when unregistering runner

What does this MR do?

This MR adds support for a new DELETE /runners/managers endpoint that accepts the system_id attribute which is then used in the UnregisterCommand whenever we're unregistering a runner that has a new glrt- token. It also changes the logic, so that the POST /runners/verify call happens earlier, at the same point in time where the runner registration happens with old tokens.

Why was this MR needed?

So that we do the right action (just delete the runner manager record, instead of the whole runner), in case a glrt- runner.

What's the best way to test this MR?

NOTE: This MR relies on behavior introduced in gitlab!119210 (merged)

1. On the Rails console, enable the :create_runner_workflow_for_instance FF:

   Feature.enable(:create_runner_workflow_for_instance)

2. Create an instance runner in the web UI: http://gdk.test:3000/admin/runners

3. Register the instance runner according to the instructions provided.

4. Unregister the instance runner with `gitlab-runner':

   gitlab-runner unregister --name '<runner name from gitlab-runner --list>'

5. Ensure that the runner manager disappeared both from config.toml and from the database. To check the database, you could do the following on the Rails console:

   # This should return an empty collection
   Ci::Runner.find_by_token("<runner-token-here").runner_managers

6. To ensure that the old behavior is still present, make sure that unregistering a runner that was registered in the legacy fashion (one that is not prefixed with glrt-) does delete the runner record. I.e.

   # This should not find a record
   Ci::Runner.find_by_token("<runner-token-here")

What are the relevant issue numbers?

gitlab#408206 (closed)