fix: Optional Map go code generation for map[string]interface{}

[TypicalDefender]

The Problem

The code generator previously failed to correctly process Avro union types defined as ["null", {"type": "map", "values": "T"}]. When it encountered a schema with such a field, the generator's logic would overlook the "null" part of the union.

As a result, it would generate a standard map type (e.g., map[string]string) instead of a pointer to a map (e.g., *map[string]string), failing to represent the field's optionality. This led to a mismatch between the Avro schema and the generated Go struct, causing potential issues during data serialization and deserialization.

---

Example of Incorrect Behavior

Let's consider the following Avro schema definition:

{
  "type": "record",
  "name": "ExampleRecord",
  "fields": [
    {
      "name": "mapTest",
      "type": ["null", {"type": "map", "values": "string"}]
    }
  ]
}

[rogpeppe]

Is that perhaps because a map in Go already has nil as a possibility so having a pointer to a map is arguably redundant?

[TypicalDefender]

Is that perhaps because a map in Go already has nil as a possibility so having a pointer to a map is arguably redundant?

Yes. Since a Go map's zero value is nil, it can already represent null. This change makes the generated code more idiomatic. Thanks for checking!