[18.0][IMP] auth_jwt: allow more authorization options over aud

[dnplkndll]

Revives #753 (closed stale
2026-02-08) with the documentation improvements requested by
@lmignon in
the prior review.

Same code as #753 (with @kobros-tech's 5 tests preserved) plus:

• Expanded help= text on audience_type, audience_type_custom,
  and audience so each form-field tooltip explains the matching
  semantics and the IdP scenarios that motivate each option.
• New section in readme/USAGE.md ("Audience type — matching
  non-standard JWT claims") covering the four audience_type values
  with a worked AWS Cognito example showing how to restrict a route by
  cognito:groups or scope.
• audience_type_custom is now required in the view when
  audience_type == 'custom' (it was previously a bare field; users
  could save a Custom validator with no payload key, which would then
  always fail at runtime).

What this PR does (recap from #753)

Some identity providers — notably AWS Cognito and several OAuth2-only
flows — mint access tokens without an aud claim but expose
authorization information under other claims (cognito:groups,
scope, vendor-specific keys). Today auth_jwt requires aud and
hard-fails on such tokens.

This PR keeps standard aud validation as the default and adds three
opt-in modes via a new audience_type selection:

• Group — match against the groups claim.
• Scope — match against the scope claim (RFC 6749 §3.3).
• Custom — match against an arbitrary payload key (e.g.
  cognito:groups, permissions).

For non-aud types the JWT library's built-in aud verification is
skipped (the token has no aud) and the configured audience list is
matched against the selected claim as a set intersection: any one
configured value present in the token authorizes the request.

Design notes (responding to @sbidoul's #753 comment)

@sbidoul suggested an expected_claim dict field (parsed with
ast.literal_eval or json) as an alternative to overloading the
audience field. We kept the selection-based approach because:

1. The four common cases (aud/group/scope/custom) cover ~95% of
   real-world IdPs and are discoverable in the form view; a free-form
   dict would let users misconfigure in subtle ways.
2. The semantics already match the audience semantics (a list of
   acceptable values; set-intersection match), so reusing the
   audience field surface is intuitive.
3. The Custom audience_type with audience_type_custom covers the
   long tail of IdPs publishing under vendor-specific claim names
   (e.g. https://example.com/claims/roles).

Happy to redesign if reviewers feel strongly — the docs make the
current approach legible enough that the discussion can happen on
substance rather than guesswork.

Note on the audience-optional split

The audience-optional change (#755)
also went stale and is closed. Not refiling here — that's a separate
concern; this PR keeps audience required across all audience_type
values (the list to match is always needed, regardless of which claim
we match against).

[dnplkndll]

@lmignon @sbidoul
added the requested changes on the stale PR