feat: support Bitbucket webhook secrets via X-Hub-Signature validation (#360)

[cdelmonte-zg]

Implements webhook secret support requested in #360.

What

When a secret is configured on a Bitbucket webhook, Bitbucket Cloud and Bitbucket Server / Data Center sign every delivery with an X-Hub-Signature header of the form sha256=<hex>, where <hex> is the HMAC-SHA256 of the request body computed with the secret as key. Until now the plugin ignored that header: the endpoint is an UnprotectedRootAction, so anyone able to reach Jenkins could POST a forged payload and trigger jobs.

This PR adds an optional Webhook secret to the plugin's global configuration, selecting a Secret text credential. When set:

• every request to the webhook endpoint must carry a valid X-Hub-Signature header;
• a missing, malformed or non-matching signature is rejected with HTTP 403, before any payload parsing or acknowledgement;
• a configured but unresolvable secret credential fails closed (403), with a SEVERE log;
• the hex comparison is constant-time (MessageDigest.isEqual).

When no secret is configured, behaviour is unchanged: unsigned requests are accepted as before, and a stray signature header is ignored.

Design notes

• Signature vs. transport encoding. Bitbucket signs the payload before any transport encoding, so the signature is validated on the request body after gzip decompression (Plugin fails to trigger jobs when Bitbucket Cloud sends gzip-compressed webhook payload (Content-Encoding: gzip) #382/fix: handle gzip-compressed webhook payloads (Content-Encoding: gzip) #383) but before the URL decoding of the legacy form-encoded path. getInputStream was split accordingly into readBody (raw bytes, post-gunzip — the HMAC input) and bodyToString (blank-check + decode, unchanged semantics).
• Validation order. Authentication runs first; the payload validation boundaries from Webhook receiver swallows undeserializable payloads: null payload triggers NPE and silent HTTP 200 instead of a clear 4xx #384 still apply afterwards (a signed but malformed payload returns 400, covered by a test).
• Global, not per-job. Validation happens at the receiver, before job matching, so the secret is global — same model as other plugins' shared webhook secret. The same secret must be configured on every webhook pointing to the Jenkins instance. Per-webhook secrets could be layered later if requested.
• Receiver no longer caches the config in a static field. The static final pinned the GlobalConfiguration instance of whichever Jenkins was alive when the class loaded, going stale across Jenkins instances (e.g. JenkinsRule tests in the same JVM). It is now resolved per call, like everywhere else in Jenkins.
• The credential is resolved on every request, so rotating the secret takes effect without a restart.

Tests

• SignatureUtilsTest (unit): known-answer vector verified independently with openssl dgst -sha256 -hmac, case-insensitive hex/prefix, empty body, tampered body, wrong secret, missing/blank header, sha1= prefix, malformed hex.
• BitBucketPPRHookReceiverSignatureTest (@WithJenkins, e2e over HTTP): signed request accepted (200), unsigned/wrong-signature rejected (403), gzip-compressed delivery validated against the uncompressed bytes (200), unresolvable credential fails closed (403), no configured secret ignores the header (200), signed but malformed payload still rejected by Webhook receiver swallows undeserializable payloads: null payload triggers NPE and silent HTTP 200 instead of a clear 4xx #384 validation (400).

Full suite green locally (311 run, 0 failures, 12 pre-existing skips) on JDK 17.

Fixes #360.