fix(uuid): coerce UUID values in process_literal_param

[RitiGrover]

Description

UUIDType.process_bind_param does the real coercion (str for native UUID columns, hex/bytes for the CHAR/BINARY fallback), but process_literal_param was a no-op that returned the raw uuid.UUID object untouched. Any literal-rendering path (literal_binds=True, Values(..., literal_binds=True), etc.) then passed an uncoerced UUID straight into the compiler.

Motivation and Context

Fixes #625. This regressed in 0.38.3. Affects the binary=False (CHAR) fallback used on dialects without native UUID support, and any dialect used with native=False - exactly the case in the original report (UUIDType(binary=False)).

How Has This Been Tested?

• Reproduced the original crash with a standalone compile-only script (no DB needed), matching the issue's own repro code
• Confirmed the fix resolves it across postgresql/mssql/mysql/sqlite dialects
• Added a regression test (test_literal_bind_non_native_fallback), confirmed it fails on the old code (CompileError: Could not render literal value "UUID(...)" with datatype CHAR(32)) and passes with the fix
• Ran the full tests/types/ suite: 1899 passed, no new failures (28 pre-existing collection errors are unrelated missing DB-driver packages in this environment)
• flake8 clean on the changed files

One thing I want to flag rather than silently leave out: UUIDType() with the default binary=True on a non-native dialect (e.g. plain MySQL) still can't be literal-rendered, because SQLAlchemy's own core BINARY type naively tries to UTF-8-decode arbitrary binary data for literal SQL. That's a separate, pre-existing SQLAlchemy-core limitation this change doesn't touch.