Support PostgreSQL's RESET SESSION AUTHORIZATION

[LucaCappelletti94]

RESET SESSION AUTHORIZATION did not parse as SESSION was taken as the parameter name.

The parser now matches both keywords before falling back to a parameter name, and gives up on the pair if the second keyword is absent, so RESET session and RESET session.foo still parse as they did.

[ting-hong-shieh]

Verified against main at 30d0836b.

RESET SESSION AUTHORIZATION
  main:  Expected: end of statement, found: AUTHORIZATION at Line: 1, Column: 15
  this:  RESET SESSION AUTHORIZATION

The no-regression claim holds: RESET session, RESET session.foo and RESET SESSION produce identical output before and after, so parse_keywords does back off when AUTHORIZATION is absent.

Worth noting for anyone checking the grammar: this form is absent from the RESET reference page, whose synopsis is only RESET configuration_parameter / RESET ALL. It is documented on the SET SESSION AUTHORIZATION page instead, whose synopsis carries RESET SESSION AUTHORIZATION and whose Notes say "The DEFAULT and RESET forms reset the session and current user identifiers to be the originally authenticated user name." So a unit variant is right — the form takes no argument — and SetSessionAuthorizationParamKind::{Default, User} remains the counterpart on the SET side.

cargo test --all-features at e69b916e: 1583 passed, 0 failed. cargo fmt --all -- --check and cargo clippy --all-targets --all-features -- -D warnings both clean.