Using the lock as an extension for `disableConcurrentBuilds(abortPrevious: true)`

### What feature do you want to see added?

Afaict the current usages of `lock` is to prevent subsequent runs from entering the current code section. However, I am trying to find a way to do the opposite, namely cancel any current jobs that have the given lock. I couldn't find a way do that even when considering `skipIfLocked`.

The workflow to support would be something like this:
- `JobA` calculates the label for the lock
- `JobA` creates the lock and starts doing a long job
- `JobB` is triggered and it calculates the same label for the lock
- `JobB` runs a snippet and cancels `JobA`, triggering a cleanup job for its current long job
- `JobB` procedes to create the lock and stats doing its long job

What I am trying to support here that `disableConcurrentBuilds(abortPrevious: true)` is to cancel the current running jobs that have a specific set of parameters, while the option `disableConcurrentBuilds` seems like it would cancel *any* job in the current piepline.

### Upstream changes

_No response_

### Are you interested in contributing this feature?

_No response_

Start by reviewing the plugin's current `lock` and `skipIfLocked` behavior, then compare it with Jenkins `disableConcurrentBuilds(abortPrevious: true)`. Define how jobs sharing a calculated lock label are cancelled, how cleanup is triggered, and when the replacement job acquires the lock; done means JobB can reliably replace JobA without affecting unrelated jobs.

Written by the indexing model from the issue text.