[fix][client] Apply Avro logical type conversions when decoding schema without classloader

[lhotari]

Motivation

AvroReader only registered logical-type conversions (UUID, decimal,
date/time, timestamp) when a non-null ClassLoader was supplied, while
AvroWriter always registers them. This asymmetry caused decoding to
fail for any logical-type field when a schema was constructed via
SchemaDefinition.builder().withJsonDef(...), where no pojo class or
classloader is provided.

For example, a UUID field encoded with Schema.AVRO(class) could not
be decoded with Schema.AVRO(SchemaDefinition.builder().withJsonDef(...))
and failed with:

java.lang.IllegalArgumentException: Can not set java.util.UUID field ... to java.lang.String

because the UUIDConversion was never registered on the reader's
ReflectData.

Modifications

• AvroReader now always builds a fresh ReflectData (using the
  supplied classloader when present, otherwise the default) and calls
  AvroSchema.addLogicalTypeConversions(...) on it, mirroring
  AvroWriter's behavior.
• Added testDecodeUuidLogicalTypeWithClass and
  testDecodeUuidLogicalTypeWithJsonDef in AvroSchemaTest to cover
  the UUID logical-type round-trip for both schema construction paths.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• The new AvroSchemaTest#testDecodeUuidLogicalTypeWithJsonDef
  reproduces the original failure and now passes with the fix.
• Existing pulsar-client schema tests continue to pass.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment