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). Ifexactly one of them will, then we shouldnot use a synthetic name likexyz_type_1; instead just use the original namexyz. (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 andtype 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 multipletypes, then go ahead and add a Property for each one.
• If there is atype ortypes, but there isalsoanyOf oroneOf, then we don't need to add anything, because the schemas in theanyOf/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, iftype is["string", "number"] but theanyOf variants are objects— but that's out of scope here.)

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