sql: support non-plpgsql CREATE LANGUAGE statements

**Is your feature request related to a problem? Please describe.**

CockroachDB rejects all `CREATE LANGUAGE` statements at parse time with an
"unimplemented" error.

PostgreSQL supports two forms of `CREATE LANGUAGE`
([gram.y:5101-5130](https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y#L5101)):

1. **Parameterless form**: `CREATE [OR REPLACE] [TRUSTED] [PROCEDURAL] LANGUAGE name`
— interpreted by PG as equivalent to `CREATE EXTENSION name`. The most
common use is `CREATE LANGUAGE plpgsql`, which client libraries and
migration frameworks (e.g. Flyway, Liquibase, Rails) often issue
defensively before creating PL/pgSQL functions.

2. **Legacy custom-PL form**: `CREATE [OR REPLACE] [TRUSTED] [PROCEDURAL] LANGUAGE name HANDLER handler_name [INLINE inline_handler] [VALIDATOR validator_function]`
— used to register a custom procedural language backed by a C handler
function. Used for languages like PL/Perl, PL/Python, PL/Tcl.

**Describe the solution you'd like**

This issue tracks implementing the parameterless `CREATE LANGUAGE` syntax
for non-plpgsql languages and is referenced by the corresponding
unimplemented error messages.

The legacy HANDLER form is not realistic to implement in the current
architecture, since CockroachDB has no C-level extension mechanism for
plugging in custom procedural languages.

Epic CRDB-60820

Jira issue: CRDB-63272