Dispatch array conversion on the SQL type category, fixing RETURNS jsonb[]

[sfc-gh-okalaci]

Stacked on #41.

The choice between building a SQL array and building a JSON array was made by comparing
the type OID against JSONOID/JSONBOID. By that point pljs_type_fill() has already
rewritten the OID to the element type — and the element type of jsonb[] is
jsonb, so an array target was indistinguishable from a scalar json target.

Those calls fell through to the scalar json branch, which stringified the entire
JavaScript array to "[object Object],[object Object]" and handed that to the json input
function. The array construction never ran:

CREATE FUNCTION f() RETURNS jsonb[] AS $$ return [{a:1},{b:2}]; $$ LANGUAGE pljs;
SELECT f();
ERROR:  cache lookup failed for type 1701470799

The OID differs from run to run — 1701470799, 2116838773, 2139062143 — because it
is read from uninitialised memory. RETURNS jsonb[] and RETURNS json[] have therefore
never worked, for any element shape: objects, scalars, strings or nested arrays.

The condition now asks the SQL type's category, which still says "array" after the
element rewrite. A bare json/jsonb target keeps turning a JavaScript array into a
JSON array, which is what the original condition was there for.

Test plan

sql/pg_jsonb_array_return.sql covers objects, scalars, nested arrays, the empty array,
json[] as well as jsonb[], a plain int[] for contrast, and — as the regression guard
— that a bare jsonb target still yields a JSON array ([1, 2, 3], jsonb_typeof =
array).

It discriminates: reverted, six statements fail with cache lookup failed for type ….
Full suite green on PostgreSQL 17 (54 tests); builds clean on 16, 18 and 19beta3.