feat: support unions in arrays

[simPod]

Q	A
Bug fix?	no
New feature?	yes
Doc updated	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#...
License	MIT

• The changes to the @type lexer/parser may support the simplest array<A|B> test case, but I can think of some edge cases that would cause that type parsing to fail. The @type typer lexer/parser currently has no union support, so this adds support for array<A|B> but there's no support for just A|B.
• The only tests seem to be of the docblockparser (which is good), but no tests of any serialization/deserialization, no tests of the Type annotation lexer changes. + @simPod I think we need also E2E test of deserialisation - I think it should already work for simple types :)
• What is the expected behaviour of A|B[] in a docblock type?

[scyzoryck]

@idbentley can you help with code review, please? :)

[scyzoryck]

@simPod I think we need also E2E test of deserialisation - I think it should already work for simple types :)

[idbentley]

My main feedback is that this PR seems rather incomplete.

The changes to the @Type lexer/parser may support the simplest array<A|B> test case, but I can think of some edge cases that would cause that type parsing to fail. The @Type typer lexer/parser currently has no union support, so this adds support for array<A|B> but there's no support for just A|B.

The only tests seem to be of the docblockparser (which is good), but no tests of any serialization/deserialization, no tests of the Type annotation lexer changes.

What is the expected behaviour of A|B[] in a docblock type?

Overall, I think this is a great feature, but needs some extra help.

[simPod]

This is indeed rather incomplete. I'm now stuck with DeserializationGraphNavigator that does not know how to handle unions.

[scyzoryck]

@simPod It seems like array<int, string> and array<int|string> will create exactly the same metadata 😓 I would consider using Union pseudo type same as for the unions, so it will be handled by the Union Handler :D