Extend Nomad CLI locking to support semaphore pattern

Today when using the Nomad CLI to acquire a lock on a variable, you are limited to one lock holder per variable path. https://developer.hashicorp.com/nomad/commands/var/lock

For uses cases where you need to coordinate a unique index across multiple instances of an allocation to coordinate writes in a shared storage path, providing a semaphore pattern would allow additional lock session holders while coordinating around re-using released lock indexes in the case of allocation failure/replacement.

Any consumer implementation would still need to obtain locks via the Nomad servers instead of relying on the local Nomad client if the session were expected to survive a Nomad client restart.

Consul supports this pattern today by leveraging the Consul session/locking primitives and abstracting the logic around finding the available lock index within the Consul CLI lock commands.
https://developer.hashicorp.com/consul/commands/lock#n
https://developer.hashicorp.com/consul/docs/automate/session?productSlug=consul&tutorialSlug=developer-configuration&tutorialSlug=distributed-semaphore&page=dynamic-app-config&page=sessions

Separately, building these patterns as part of a native Nomad job spec capability will make sense to ensure the patterns are adopted in a manner that correctly coordinates the lock without relying on the local client. This will be visited in a future issue.

Start with the Nomad CLI var lock command and compare its behavior with the linked Consul CLI lock and distributed-semaphore documentation. Determine how multiple holders and reusable lock indexes should be coordinated through Nomad servers rather than a local client. Done means the CLI supports the semaphore pattern while preserving session behavior across client restarts.

Written by the indexing model from the issue text.