Add Client.ReleaseByToken for cross-process lock release

[Yusufihsangorgel]

Closes #81.

Lock.Release needs the *Lock that Obtain returned — its fields are unexported, so
a different process that only persisted the token has no way to construct one.
The workaround is re-Obtain-ing with the same token, which reopens the split-second
unlocked window this issue is about.

Adds Client.ReleaseByToken / ReleaseMultiByToken, backed by a new release_token.lua
that does the same atomic getrange-prefix check obtain.lua already uses for
token-based re-acquisition (canOverrideKeys), instead of the full token+metadata
value release.lua requires. So the caller only needs the key and token — same
inputs as Options.Token.

lock, _ := locker.Obtain(ctx, "my-key", time.Minute, &redislock.Options{Token: "abc"})
// token persisted elsewhere; different process, later:
err := locker.ReleaseByToken(ctx, "my-key", "abc")

Named it ReleaseByToken rather than Release since Lock embeds *Client — a
same-named Client.Release would be legal Go but would sit shadowed behind Lock's
own Release(ctx), which seemed worth just avoiding.

Doesn't touch any FenceKey counter, matching Lock.Release's existing behaviour
(per #94, the fence counter is meant to keep advancing regardless of release path).

Tests: TestClient_ReleaseByToken, TestClient_ReleaseByToken_with_metadata,
TestClient_ReleaseByToken_wrong_token, TestClient_ReleaseByToken_not_held.