Remove Optional[...] special-casing during semantic analysis

[ilevkivskyi]

This is another fix for recursive aliases. Ref #13297

Previously this special casing caused Optional[...] to fail with infinite recursion, where Union[..., None] worked. I also delete a duplicate helper, and replace it with another existing one that handles type aliases properly.

(I have no idea why some TypeGuard test started passing, but we have xfail-strict so I am re-enabling this test.)

cc @JukkaL

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

discord.py (https://github.com./Rapptz/discord.py)
- discord/interactions.py:163: error: Incompatible types in assignment (expression has type "object", variable has type "Union[ChatInputApplicationCommandInteractionData, UserApplicationCommandInteractionData, MessageApplicationCommandInteractionData, ButtonMessageComponentInteractionData, SelectMessageComponentInteractionData, ModalSubmitInteractionData, None]")
+ discord/interactions.py:163: error: Incompatible types in assignment (expression has type "object", variable has type "Union[Union[ChatInputApplicationCommandInteractionData, UserApplicationCommandInteractionData, MessageApplicationCommandInteractionData], Union[ButtonMessageComponentInteractionData, SelectMessageComponentInteractionData], ModalSubmitInteractionData, None]")

[ilevkivskyi]

Error message in mypy_primer looks a bit more verbose, but it is because nested unions are aliases. If we will switch to showing alias names instead in error messages, it will be much more compact.