Fixes #1120.

There are two related changes here:

First, when processing the anyOf/oneOf items in a union, check whether each item will generate a named Python class (i.e. is it an enum or a model). If exactly one of them will, then we should not use a synthetic name like xyz_type_1; instead just use the original name xyz. (If more than one of them will, then we do need to add name suffixes; if none of them will, then it doesn't really matter since none of the synthetic names will show up in Python code anyway).

That fixes the case described in the issue where nullable object/enum classes got an unnecessary "Type1" suffix. It's a breaking change, but, I think, a desirable one— I don't think anyone prefers to have "Type1" added in those cases, and depending on that would be a bad idea anyway since it's an obscure implementation detail. So I haven't gated it behind a config option.

Second, if we're creating a union and type has been explicitly specified— these were the cases where a bunch of spurious -Type1, -Type2Type1, etc. were being created, because of faulty logic that assumed every explicit type had to be added separately to the union. I believe the correct behavior is:

• If the union is just because there are multiple types, then go ahead and add a Property for each one.
• If there is a type or types, but there is also anyOf or oneOf, then we don't need to add anything, because the schemas in the anyOf/oneOf list already describe what kind of values there can be. (We could add a check to make sure the types aren't contradictory— for instance, if type is ["string", "number"] but the anyOf variants are objects— but that's out of scope here.)

The second issue was also the reason for the weird behavior of nullable with enums in 3.0, because we are handling nullable by converting the type into a union.