Take composite OIDs from the caller instead of guessing 16385

[adriangb]

Closes #96 (item 1; item 2, Json.oid(), is #100). Breaking, deliberately batched into the
pending semver-major.

The bug

PostgresType::UserDefined::oid() returned a hard-coded 16385. Postgres tolerated that only
because it assumes an OID it does not recognise belongs to a sender-side type — and 16385 is
the first OID a cluster hands out for user objects. On any database that has ever created a
user-defined type, record_recv finds a real (and different) type at 16385 and rejects the COPY.
Fresh embedded test clusters never have one, which is why the suite never saw it.

pgpq cannot know a composite's OID: the server allocates it when the type is created. So the
caller supplies it.

API

let encoder = ArrowToPostgresBinaryEncoder::try_new(&schema)?
    .with_composite_oids(&HashMap::from([("s_t".into(), oid_from_pg_type)]))?;

• PostgresType::UserDefined carries oid: Option<u32>.
• StructEncoderBuilder::with_oid for one, ArrowToPostgresBinaryEncoder::with_composite_oids
  for a whole map — keyed by the type name the generated DDL uses (<field>_t), which is what
  you look up in pg_type after running the DDL. Unknown names are reported, so a typo fails
  loudly instead of silently leaving the wrong OID in place.
• Exposed to Python as ArrowToPostgresBinaryEncoder.with_composite_oids(mapping), with a stub
  entry.

Behaviour change

Encoding a nested composite without its OID is now an error that names the type and the query
that finds it:

field s is a composite type whose OID in the target database is unknown; supply it with
`with_composite_oids` (look it up with `select oid from pg_type where typname = 's_t'`)

Building the encoder tree still succeeds — the OID arrives afterwards — so only shapes that can
never carry an OID (arrays of composites, arrays of arrays) still fail at construction, as
before. This is the one judgement call worth flagging: it turns a silent wrong-OID-on-the-wire
into an explicit error, at the cost of requiring nested-struct callers to do a lookup they
previously got away without on a fresh database.

Tests

• The roundtrip harness now creates the types, asks pg_type for the OIDs it just allocated, and
  encodes with those — so the suite no longer depends on any composite landing on a particular
  OID.
• nested_composite_uses_the_databases_own_oid creates unrelated types first to force the
  composite off 16385, asserts the real OID differs, asserts the encoded bytes carry it (and
  differ from the placeholder encoding), and roundtrips successfully.
• Python: test_nested_struct_needs_composite_oids covers the raise, the success with the OID
  declared, and the unknown-name error.

The byte-exact snapshots still encode with 16385 — that is what produced them and what a fresh
cluster allocates — but that value now lives in the test harness where it is visible, rather than
in the library where it applied to every user's database.