Improve schemas for non-total TypedDict

[giograno]

TypedDicts in Python can be marked with total=None. This means that omitting a field still results in a valid structure.
It gets trickier when non-total TypedDicts have also nullable fields.

For instance, imagine the following structure:

class PyType(TypedDict, total=False):
    height: int | None
    weight: int | None

The resulting schema would be something like that:

{
  "type": "record",
  "name": "PyType",
  "fields": [
    {
      "name": "height",
      "type": [
        "long",
        "null"
      ]
    },
    {
      "name": "weight",
      "type": [
        "long",
        "null"
      ]
    }
  ]
}

Now, imagine the two following objects.

obj = PyType(height=180, weight=None)
obj2 = PyType(height=180)

The schema would fit both the Avro representation, but does not let us distinguish the case in which weight is explicitly set to None from the case in which it is not set at all.

With this PR, we extend the types of the fields of a non-total TypedDict with string. This is going to be useful for all clients to mark a field as explicitly missing. Eveyrhing would make more sense if you look at the mentioned PR using this feature.

Addresses PNX-545

[bentsku]

LGTM, this looks good! Nice fix to a tricky solution, a None type hint can mean a lot for non-total typed dicts, so I think this a good way to solve that 👍

[bentsku]

might be worth to add a str | None here just to verify what happens when we do Union[str, None, str]?

[giograno]

Done in c514ae0. Union can't have duplicates, so it would just be Union[str, | None]. If you actually try to create a type alias like this, you'd get a Optional[str] :)

[bentsku]

question: so here the regular str is not added, so would that work if we add the special marker to a Opt enum type? seems like yes as your comment in the deduplication logic

[giograno]

Yes, it would. {"namedString": "Opt", "type": "string"} is totally equivalent to "type": "string" for Avro.